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Introduction 


Failure  to  keep  operating  system  and  application  software  up  to  date  is  the  most 
common  mistake  made  by  information  system  professionals  and  users. 
Unfortunately,  despite  extensive  testing,  all  operating  systems  and  applications  are 
released  with  “bugs”  (errors  in  the  software)  that  affect  security,  performance  and 
stability.  Most  estimates  for  the  number  of  bugs  in  published  software  range  from  5 
up-to  20  bugs  per  1000  lines  of  code.  Most  of  these  bugs  do  not  represent 
significant  errors  and  do  not  affect  the  performance  or  security  of  a  system,  and 
therefore  are  not  usually  noticed.  They  do  sometimes ,  hHowever,  some  may  have 
a  negative  impact  on  security  and  performance.  (This  last  sentence  contradicts  the 
second  to  last  regarding  security.) 

As  software  programs  expand,  the  potential  number  of  bugs  grows.  Windows  3.1, 
released  in  1992,  had  an  estimated  3  million  lines  of  code."  Thus  according  to 
common  opinions  it  would  contain  an  estimated  15,000  to  60,000  potential  bugs 
within  Windows  3.1.  In  1999,  Windows  2000  was  released.  Estimates  for  the 
number  of  lines  of  code  within  Windows  2000  differ  by  as  much  as  30  million  lines. 
With  a  low  estimate  of  35  million  lines  of  code  there  would  be  a  175,000  to  700,000 
potential  bugs  within  Windows  2000.  In  1992,  the  first  graphical  user  interface 
(GUI)  version  of  Linux  was  released  with  about  170,000  lines  of  code,  equating  to 
an  estimated  850  to  3,400  potential  bugs  in  the  software.  With  the  release  of  a 
distribution  of  Linux,  RedHat  7.1  in  2001,  the  number  of  lines  of  code  has  grown  to 
about  30  million.  This  equates  to  an  estimated  1 50,000  to  600,000  potential  bugs  in 
RedHat  7.1. 

These  bugs  are  generally  discovered  only  after  a  large  number  of  users  start  using 
the  software  and  hackers  start  attempting  to  compromise  it.  Once  a  bug  is 
discovered,  the  software  manufacturer  often  releases  a  piece  of  software  to  correct 
the  bug.  This  software  is  often  called  a  patch,  hotfix,  or  service  pack. 

Today  more  than  ever,  timely  patching  is  critical  to  maintaining  the  operational 
availability,  confidentiality,,  and  integrity  of  information  systems.  New  patches  are 
released  daily  and  it  is  often  difficult  even  for  experienced  system  administrators  to 
keep  abreast  of  all  the  new  patches. 

Generally  speaking  patches  are  released  for  two  reasons: 

•  To  fix  faults  in  an  application  or  operating  system.  An  example  of  this  is  a 
security  hotfix  for  Microsoft’s  Internet  Information  Server  (IIS).  Many 
hacker  attacks  are  based  on  exploiting  faults  in  the  computer  code  of 
applications  and  operating  systems.  Patches  are  also  released  to  correct 
performance  or  functionality  problems. 

•  To  add  functionality  or  to  address  a  new  security  threat.  An  example  of  this 
is  new  virus  definitions  for  an  anti-virus  application.  There  was  nothing 
“wrong”  with  the  code  of  the  anti-virus  program,  but  it  had  to  be  updated  to 
detect  new  viruses  hat  did  not  exist  when  the  applications  was  first 
released. 


1  Throughout  this  document  examples  of  bugs  and  software  applications  will  be  employed  for  illustrative 
purposes  only.  This  does  not  mean  to  imply  that  product  is  defective  or  that  it  should  not  be  used. 
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The  recent  outbreaks  of  the  Code  Red  and  Nimda  worms  show  why  patching  is  so 
critical.  During  June  2001,  a  network  security  company  discovered  a  serious 
vulnerability  in  Microsoft  IIS  web  server  application.  Within  days,  Microsoft  released 
a  patch  to  eliminate  the  vulnerability;  many  system  administrators  did  not  update 
their  systems.-  In  July  the  Code  Red  worm,  exploiting  the  vulnerability  discovered  in 
June,  infected  more  than  300,000  computers  in  1  week  despite  the  fact  that  the 
patch  had  been  available  for  several  weeks.  Unfortunately,  people  did  not  learn 
from  the  experience.  Within  two  months,  the  even  more  virulent  Nimda  (admin 
spelled  backwards)  virus  which  exploited  multiple  vulnerabilities  (for  which  patches 
existed),  infected  thousands  of  additional  computers.  Neither  of  these  viruses 
would  have  had  much  effect  if  not  for  thousands  of  computer  administrators 
neglecting  to  patch  their  systems. 

CERT2  (http://www.cert.org)  estimates  that  95  percent  of  all  network  intrusions 
could  be  avoided  by  keeping  systems  up  to  date  with  appropriate  patches.  In  an 
increasingly  interconnected  world,  it  is  critical  that  system  administrators  keep  their 
systems  patched  to  the  most  secure  levelwith  the  most  recent  updates  and/or 
releases.  Doing  so  significantly  reduces  the  security  vulnerabilities  of  their  systems. 

Purpose  and  Scope 

This  document  provides  guidance  for  system  administrators  and  technical 
managers  processes  and  procedures  for  installing  and  verifying  on  when  and  how 
to  check  for  and  install  application  and  operating  system  patches.-  It  describes  how 
to  keep  apprised  of  patch  releases  and  when  and  how  to  install  patches. 

This  document  does  not  address  specific  patches  or  vulnerabilities  (except  as 
examples)  or  how  they  might  be  mitigated.  However,  it  does  present  a  systematic 
approach  for  identifying  and  installing  necessary  patches.  Following  this  systematic 
approach  will  potentially  reduce  the  number  of  vulnerabilities  incidents  to  which  a 
network  may  be  subject. 


Audience 


This  document  is  written  for  system  administrators,  technical  managers,  functional 
managers,  and  other  information  technology  (IT)  staff  members  who  manage 
information  systems.  It  provides  a  structured  approach  to  identifying  and 
implementing  security  patches. — Management  personnel  who  are  responsible  for 
systems  can  use  the  topics  discussed  in  this  document  to  become  familiar  with  the 
status  of  the  assets  under  their  stewardship.  This  document  can  also  assist 
personnel  in  evaluating  their  compliance  with  their  organization’s  security  standards 
and  requirements.  .Finally,  management  personnel  can  use  this  guide  to  provide  a 
technical  basis  for^-and  support  during  decision-making  processes. 


2  Note:  CERT  is  no  longer  an  acronym;  it  does  not  stand  for  anything.  Previously,  it  stood  for  Computer 
Emergency  Coordination  Team.  (I  believe  within  POD,  “CERT'  remains  a  valid  acronym.) 
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Implementing  A  Patch  Application  System 


Given  the  number  of  patches  and  tbe-complexity  inherent  toot  any  but  the  most 
basic— information  networks,  most  organizations  need  to  create  a  systematic 
approach  to  identifying  and  applying  patches  is  essential.  This  approach  will  vary 
from  organization  to  organization  depending  on  the  organizations  structure,  threat 
level,  and  security  posture.  Each  organization  will  need  to  create  its  own  system 
that  addresses  its  particular  needs  and  priorities.  The  system  must  be  a 
collaborative  effort  created  bv  the  system  andamona  network  administrators, 
security  officers,  and  management  in  order  to  fully  reflect  meet  the  needs  of  the 
organization. 

Although  each  organization  will  rank  its  precautions  and  issues  differently,  all 
patched  application  and  operating  systems  will  include  the  following: 

•  Identification  of  applicable  vulnerabilities  and  patches 

•  Testing  of  patches 

•  Deployment  of  patches. 

Each  of  these  steps  is  summarized  bellows  in  and  discussed  greater  detail  in  later 
sections  of  this  document. 

(NOTE:  There  is  a  little  bit  of  a  disconnect  here.  The  introduction  identifies  patches 

to  “application”  and  “operating  systems.”  The  above  paragraph  uses  more  specific 

language  of  “application  systems.”  This  is  a  hybrid  of  what  was  previously 

presented  as  distinct  elements.  I  started  to  make  some  changes  and  have  decided 

to  stop,  pending  clarification.  I  would  recommend  you  maintain  the  more  specific 

language  of  “application  software”  and  “operating  systems.” 

Identifying  Applicable  Vulnerabilities  and  Applicable  Patches 

At  all  times,  a  group  or  individual  should  be  responsible  for  identifying  vulnerabilities 
in  the  current  production  system  and  locating  any  associated  patches  or  mitigation 
techniques.  -Priorities  at  this  level  should  include  identifying  patches  in  a  timely 
manner  for  the  most  critical  or  threatened  systems,  implementing  mitigation 
techniques  to  tbe-lessen  the  risk  associated  with  the  vulnerability  until  the  patch  can 
be  tested  and  applied,  and  identifying  the  experiences  of  others  in  using  the  patch 
to  assist  in  the  testing  and  deployment  phases.  (NOTE:  This  paragraph  speaks  to 
both  itself  and  the  subseouent  paragraphs  of  “testing  patches”  and  “deploying 

patches.”  The  paragraph  goes  on  to  introduce  some  very  worthwhile  priorities  such 

as  “implementing  mitigation  techniques”  and  “identifying  experiences...”  There  are 

no  subsequent  discussions  of  each  (as  there  is  with  “testing  patches”  and 

“deploying  patches”,  which  might  be  both  useful  and  logical.  For  example...  the 

reason  it  is  important  to  “identify  experiences”  is  to  ensure  the  ultimate  instructions 

that  accompany  dissemination  of  a  patch  are  properly  executed.  Improperly 

executed  patches  can  leave  a  system  eouallv  if  not  more  vulnerable.) 

Testing  Patches 

Patches  always  need  to  be  tested.  Testing  Ssometimes  occurs  in  conjunction  with 
deployment  (e.g.,  when  a_patch  is  applied  directly  to  production  system)  and  at 
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other  times  occurs  prior  to  deployment  (e.g.,  when  a  patch  is  applied  to  a  test 
system  preceding  deployment).  There  are  advantages  and  disadvantages  to  both 
options  that  are  discussed  in  greater  detail  later. 

There  are  two  types  of  testing  that  need  to  be  conducted  on  a  patch.  One,  the 
patch  needs  to  be  tested  to  ensure  that  it  as-does  not  affected  negatively  affect  the 
performance  of  the  system  negatively.  Two,  the  patch  also  needs  to  be  tested  to 
ensure  it  has  adequately  corrected  the  vulnerability. 

Deploying  of  Patches 

Only  after  the  patch  (or  bundle  of  patches)  has  been  completely  verified  and  tested 
in-should  it  be  deployed  to  or  throughoutin  the  production  environment  (there  are 
some  exceptions  to  this  rule  discussed  later).  Methods  should  be  developed  to 
automate  the  deployment  as  much  as  possible.  This  not  only  reduces  the  cost  of 
staff-hours  required  to  manually  deploy  the  patch,  but  also  minimizes  the  risk  of 
human  error.  If  the  patch  is  not  deployed  properly,  it  has  a  higher  risk  of  introducing 
new  vulnerabilities. 

See  Figure  1  for  an  example  of  a  simplified  patch  application  system.  (NOTE:  it 
might  be  useful  for  this  diagram  to  use  the  same  language  as  used  above  in 

describing  the  system.  The  above  words  should  describe  this  system  in  the  form  of 

a  coherent  word  picture.  For  example. .  .the  arrow  on  the  box  for 
“Development/Testing”  points  to  itself.  I’m  unclear  on  its  intent  or  the  implication.) 


Figure  1  —  Patch  Application  System 
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Identifying  New  Patches  and  Vulnerabilities 


Perhaps  the  most  difficult  part  of  the  patching  process  for  most  system 
administrators  is  keeping  abreast  of  all  of  the  latest  developments  in  patches  and 
updates.  This  can  be  a  monumental  task,  particularly  for  system  administrators 
responsible  for  maintaining  a  heterogeneous  environment.  Statistics  in  eWeek  and 
Security  Focus,  two  on-line  publications,  show  overwhelming  this  undertaking  can 
be.  According  to  eWeek  (http://www.eweek.comt  Microsoft  has  released  more  than 
21  security  bulletins  for  Internet  Information  Server  5.0  alone  in  just  1  year.  Security 
Focus  lhttp://www.secutitvf ocus.com)  estimates  that  60  new  security  patches  are 
released  every  month.  To  make  matters  worse,  system  administrators  must  watch 
two  different  (but  related)  moving  targets:  patches  and  vulnerabilities.  Patches,  as 
discussed  below,  are  released  to  fix  problems  in  software  these  are  often,  but  not 
always,  security  related. 

Vulnerabilities  are  weaknesses  in  software  that  can  be  exploited  by  a  malicious 
entity  to  gain  greater  access  and/or  permission  than  it  is  authorized  to  have  on  a 
target  computer.  Not  all  vulnerabilities  have  related  patches,  and  thus  system 
administrators  must  be  aware  of  vulnerabilities  as  well  as  patches  and  must  mitigate 
“unpatched”  vulnerabilities  though  other  methods  (firewalls,  router  access  control 
lists,  etc.).  It  is  a  common  mistake  among  system  administrators  to  monitor  only 
patches  and  not  vulnerabilities.  Although  this  omission  is  understandable  given  the 
time  pressures  many  system  administrators  face,  it  can  crease  serious  problems 
since  that  the  system  administrator’s  chief  adversary,  the  hacker,  spends  most  of 
his  or  her  time  monitoring  and  exploiting  vulnerabilities.  The  number  of  new 
vulnerabilities  being  discovered  is  increasing  each  year.  CERT 
(https://www.cert.org)  reports  a  dramatic  increase  since  1995  (see  Table  1). 


Table  1  —  Number  of  New  Vulnerabilities  Reported  to  CERT 


Year 

Vulnerabilities 

1995 

171 

1996 

345 

1997 

311 

1998 

262 

1999 

417 

2000 

1,090 

2001  (first  half) 

1,151 

The  system  administrator  has  numerous  resources  at  his  or  her  disposal  to  monitor 
the  status  of  patches  and  vulnerabilities  for  the  systems  he  or  she  support.  Each 
type  of  resource  has  its  own  strengths  and  weaknesses.  Often  a  system 
administrator  will  want  to  refer  more  than  one  to  ensure  timely  knowledge  of  new 
patch  releases  and  vulnerabilities.  The  most  common  forums  for  monitoring  the 
release  of  patches  and  identification  of  vulnerabilities  are: 

•  Vendor  websites 
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Vendor  mailing  lists 


•  Third-party  websites 

•  Third-party  mailing  lists  and  newsgroups 

•  Other  notification  tools. 

Note:  This  section  will  not  provide  specific  examples  of  these  resources.  However, 
Appendix  A  provides  lists  of  resources  for  commonly  used  applications  and 
operating  systems. 

Vendor  Websites 

Vendor  websites  are  probably  the  most  popular  source  of  information  used  by 
system  administrators  to  learn  of  new  patches.  These  sites  offer  significant 
amounts  of  information  and  are  generally  the  primary  sources  of  patches.  Vendor 
websites  offer  several  advantages: 

•  Most  patches  are  released  by  vendors. 

•  Often  the  vendor  website  is  the  only  reliable  place  to  acquire  a  patch  (be 
suspicious  of  patches  from  third-party  sources). 

•  Vendors  often  provide  a  wealth  of  information  on  vulnerabilities,  methods  of 
mitigation,  and  instructions  on  installing  and  using  patches. 

•  Vendors  often  have  unparalleled  expertise  concerning  their  products. 
Vendor  website  limitations: 

•  These  sites  provide  no  active  notification  (system  administrator  must  the 
effort  to  visit  and  review  the  site  frequently). 

•  Vendors  may  not  provide  all  relevant  information  (or  alternative  mitigation 
procedures). 

•  System  administrators  managing  a  heterogeneous  environment  may  have 
to  peruse  numerous  vendor  websites  for  the  various  products  they  support. 

•  There  is  frequently  a  several-day  delay  between  the  time  a  vulnerability  is 
discovered  and  the  time  the  vendor  releases  a  patch  (unfortunately,  many 
vendors  will  not  report  the  vulnerability  unt  il  the  patch  is  released). 

Vendor  Mailing  Lists 

Mailing  lists  are  a  more  interactive  way  for  vendors  to  interact  with  the  users  of  their 
software.  A  mailing  list  is  nothing  more  than  a  massive  list  of  users  that  have 
requested  to  be  included  on  a  particular  list  (i.e.,  subscribers).  Many  larger  vendors 
maintain  mailing  lists  that  allow  them  to  send  e-mail  messages  and  notifications  of 
patches  and  updates  to  the  users  of  their  products.  (Some  vendors  prefer  to  rely  on 
newsgroups  [see  section  below]). 
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Vendor  mailing  lists  offer  similar  advantages  to  vendor  websites: 

•  Most  patches  are  released  by  vendors. 

•  Use  of  a  mailing  list  does  not  require  a  system  administrator  to  visit  a 
website  instead,  notification  is  sent  by  e-mail  to  the  system  administrator’s 
inbox. 

•  Vendors  often  provide  a  wealth  of  information  on  vulnerabilities,  methods  of 
mitigation,  and  instructions  on  installing  and  using  the  patch. 

•  Vendors  often  have  unparalleled  expertise  concerning  their  products. 
Vendor  mailing  list  limitations  include: 

•  The  vendor  may  not  always  provide  all  relevant  information  (or  alternative 
mitigation  procedures). 

•  System  administrators  managing  a  heterogeneous  environments  may 
have  to  subscribe  to  numerous  vendor  mailing  lists  for  the  different 
products  they  support,  which  may  overwhelm  their  inboxes  with  e-mails. 

•  Vendors  sometimes  succumb  to  the  temptation  to  use  their  mailing  lists  for 
marketing  email  (SPAM),  which  may  cause  administrators  to  ignore  or 
“filter”  all  messages  from  the  list. 

•  There  is  often  a  several-day  delay  between  the  time  a  vulnerability  is 
discovered  and  the  time  the  vendor  sends  an  email  notification,  due  to 
vendor  reluctance  to  provide  information  on  a  vulnerability  before  a  patch 
release. 

Third-Party  Websites 

Third-party  websites  are  not  maintained,  or  generally  endorsed,  by  product  vendors. 
These  websites  may  cover  a  large  number  of  vendors  and  products  or  may 
specialize  in  a  specific  vendor  or  product.  They  are  often  report  new  vulnerabilities 
before  the  vendor  because  the  latter  often  delay  notification  until  they  have 
confirmed  the  vulnerability  and  created  a  patch  or  other  mitigation  techniques. 

Third-party  websites  offer  several  advantages: 

•  Timely  release  of  new  vulnerabilities  (as  noted  above). 

•  Depending  on  the  site: 

o  Coverage  of  more  than  one  vendor  or  product  allowing  the  system 
administrator  to  visit  fewer  websites  to  gather  information  (i.e., 
“one  stop  shopping”) 

o  Specialization  in  a  particular  product  (saving  the  administrator  time 
since  he  or  she  does  not  have  to  navigate  through  unrelated  data). 
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Provision  of  potentially  more  acceptable  alternatives  to  the  official 
mitigation  techniques  provided  by  the  vendor 


•  Provision  of  information  that  the  vendor  chooses  not  to  provide. 

The  limitations  of  third-party  websites  include: 

•  No  active  notification  (the  system  administrator  must  make  the  effort  to  visit 
and  review  the  site  frequently). 

•  Administrators  need  to  be  cautious  of  third-party  patches. 

•  May  not  include  all  needed  resources  (e.g.,  patches  available  at  vendor 
sites). 

Third-Party  Mailing  Lists  and  Newsgroups 

The  primary  advantage  of  third-party  mailing  lists  and  newsgroups  is  that  they  allow 
system  administrators  and  other  users  to  interact  supporting  two-way 
communications  where  vendor  mailing  lists  support  only  one-way  (vendor  to  user) 
communications.  This  allows  administrators  to  share  their  experiences  and  ask 
questions.  The  principal  difference  between  a  newsgroup  and  mailing  list  is  that 
newsgroup  is  an  “officially”  recognized  Internet  forum  and,  as  such,  can  only  be 
established  by  following  fairly  lengthy  procedures.  In  contrast,  anybody  with  a  mail 
server  and  Internet  access  can  set  up  a  mailing  list.  Also  mailing  lists  may  be 
moderated  and  membership  controlled. 

The  advantages  of  third-party  mailing  lists  and  newsgroups  include: 

•  Allow  interaction  between  administrators 

•  Do  not  require  a  system  administrator  to  visit  a  website  (information  is  sent 
via  e-mail  to  his  or  her  inbox) 

•  Allow  system  administrators  to  learn  directly  from  the  experiences  of  others 
(e.g.,  are  there  problems  associated  with  a  particular  patch,  does  it  really 
correct  the  problem). 

Third-party  mailing  list  and  newsgroups  limitations  include: 

•  Because  third-party  mailing  lists  generally  allow  anyone  to  participate,  they 
tend  to  generate  large  amounts  of  e-mail  this  may  overwhelm  the  valuable 
data.  This  problem  is  sometimes  referred  a  low  signal-to-noise  ratio. 

•  Administrators  must  be  careful  what  information  they  release  on  the  mailing 
list,  because  malicious  entities  might  watch  the  list  (for  example,  an 
administrator  who  says  his  or  her  system  is  having  a  problem  with  security 
in  a  particular  area  may  invite  hackers  to  try  to  exploit  that  vulnerability.) 

•  Administrators  need  to  be  cautious  of  third-party  patches. 

•  Many  newsgroups  have  high  levels  of  advertising  messages  (Spam)  which 
are  often  annoying  and  offensive. 
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Administrators  must  be  careful  to  verify  the  information  they  receive  from 
these  forums,  since  there  is  generally  no  way  to  verify  the  source. 


Other  Notification  Tools 

As  the  task  of  keeping  up  with  releases  of  patches  and  reports  of  vulnerabilities  has 
become  more  burdensome,  new  tools  and  applications  have  been  created  to  allow 
system  administrators  to  receive  automated  and  customized  notifications  for  the 
systems  they  support.  These  tools  are  provided  both  by  vendors  (e.g.,  Microsoft's 
Critical  Update  Notification  application)  and  by  third  parties  (e.g.,  Cassandra  and 
Security  Focus  SIA).  For  more  information  on  obtaining  these  and  similar  products, 
see  Appendix  A.  Some  of  these  products,  such  as  Cassandra,  are  free,  while 
others  require  a  one-time  fee  or  subscription. 

The  advantages  of  these  notification  tools  include: 

•  They  are  customizable  so  that  notification  can  be  limited  to  those 
applications  and  operating  systems  of  interest  (reducing  the  time  spent 
scrutinizing  multiple  alerts  that  do  not  apply  to  one's  systems) 

•  They  provide  real-time  alerts  to  the  administrator  (e.g.,  not  requiring  him  or 
her  to  visit  a  web  page). 

The  disadvantage  of  these  notification  tools  include: 

•  Cost  (for  fee-based  services). 

•  Information  quality  (these  sources  are  only  as  good  as  the  underlying 
information  database). 

•  Lag  time  inherent  in  certain  of  these  services. 
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Specific  Vulnerability  Identification  Resources 


This  section  identifies  specific  resources  administrators  can  use  to  identify 
vulnerabilities  and  patches  for  their  systems.  The  section  discusses  vendor  and 
third-party  web  sites  as  well  as  applications  that  assist  the  administrator  in 
discovering  vulnerabilities  and  applying  patches.  These  resources  are  just  a  few  of 
the  many  that  are  available  and  many  additional  resources  are  provided  in 
Appendixes  A-G. 


Mitre  CVE 


Mitre’s  Common  Vulnerabilities  and  Exposures  (CVE)  (http://cve.mitre.org)  is  a  list 
of  standardized  names  for  vulnerabilities  and  other  information  security  exposures. 
The  principal  goal  of  CVE  is  to  standardize  the  names  for  all  publicly  known 
vulnerability  and  security  exposures.  This  list  should  be  considered  a  dictionary 
NOT  a  database  (like  some  other  websites  that  will  be  discussed  later  in  this 
section).  The  standardization  provided  by  the  CVE  makes  it  easier  to  share  data 
among  separate  vulnerability  databases  and  security  tools.  The  CVE  is: 

•  A  dictionary  rather  than  a  database 

•  Accessible  for  revi  ew  or  download  from  the  Internet 

•  Industry-endorsed  via  the  CVE  Editorial  Board. 

The  CVE  provides: 

•  A  single  name  for  each  vulnerability  or  exposure 

•  A  standardized  description  of  each  vulnerability  or  exposure 

•  A  means  for  disparate  databases  and  tools  to  speak  the  same  language 
(e.g.,  one  tool  can  interpret  the  results  of  another  since  they  both  recognize 
the  CVE  name  for  a  given  vulnerability) 

•  A  path  to  interoperability  and  better  security  coverage 

•  A  basis  for  comparing  among  tools  and  databases. 

CVE  was  created  because  although  most  information  security  tools  include  a 
database  of  security  vulnerabilities  and  exposures,  there  is  significant  variation 
among  them  and  no  easy  way  of  ascertaining  when  different  databases  are 
referring  to  the  same  problem.  The  consequences  of  these  disparities  are  potential 
gaps  in  security  coverage  and  no  effective  interoperability  among  the  disparate 
databases  and  tools.  In  addition,  each  tool  vendor  currently  uses  different  metrics  to 
state  the  number  of  vulnerabilities  or  exposures  it  detects,  meaning  that  there  is  no 
standardized  basis  for  evaluation  among  the  tools. 

Through  use  of  a  standard  list  of  vulnerabilities  and  exposures  such  as  CVE, 
databases  and  tools  can  communicate  in  a  common  language.  This  means  that  IT 
security  professionals  will  know  exactly  what  each  tool  covers,  because  CVE  gives 
them  a  baseline  for  evaluating  the  coverage.  As  a  results,  IT  security  professionals 
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can  determine  which  tools  are  most  effective  and  appropriate  for  their  organization’s 
needs.  In  short,  CVE-compatible  tools  and  databases  will  give  administrators  better 
coverage,  easier  interoperability,  and  enhanced  security. 

The  CVE  Editorial  Board  makes  decisions  on  which  vulnerabilities  and  security 
exposures  should  be  included  in  the  CVE.  The  board  includes  members  from 
numerous  information  security  related  organizations  including  commercial  security 
tool  vendors,  academia,  research  institutions,  government  agencies,  and  other 
prominent  security  experts. 

Through  open  and  collaborative  discussions,  the  board  identifies  which 
vulnerabilities  or  exposures  are  to  be  included  in  the  CVE,  and  then  determines  the 
common  name  and  description  for  each  entry.  The  process  begins  with  the 
discovery  of  a  potential  security  vulnerability  or  exposure.  The  information  is  then 
assigned  a  CVE  candidate  number.  The  Editorial  Board  discusses  the  candidate 
and  votes  on  whether  or  not  it  should  become  a  CVE  entry.  If  the  candidate  is 
accepted,  it  is  entered  into  the  CVE  and  published  on  the  CVE  website.  Candidates 
can  be  searched  on  the  site,  but  the  CVE  and  candidates  lists  are  separate.  (See 
Figure  2  for  more  information  on  the  CVE  naming  process.) 


Submissions  Candidates 

Raw  information  Placed  In  dusters 


Entries 
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Figure  2  — CVE  Naming  Process 

As  of  September  2001,  the  CVE  contained  1,604  official  entries.  In  addition,  the 
CVE  Editorial  Board  was  evaluating  1 ,796  candidates. 

Searching  the  CVE 

The  CVE  offers  several  methods  of  searching  its  list  of  vulnerabilities  and 
exposures  (Figure  3). 
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Figure  3  —  CVE  Search 

Users  can  view  the  entire  CVE  list  or  candidates  list  by  clicking  on  the  appropriate 
view  button  in  the  purple  “View  CVE”  square.  This  will  list  all  the  CVE  or  candidate 
entries  starting  with  the  earliest.  Users  can  also  download  the  CVE  or  candidate 
lists  in  their  entirety  in  variety  of  formats  by  clicking  on  the  appropriate  button  in  the 
green  “Download”  square.  Users  may  freely  download,  copy,  redistribute,  and 
reference  the  CVE  but  they  may  not  modify  them.  Users  of  the  CVE  can  also 
search  each  list  via  keyword  or  the  CVE  or  candidate  name. 

While  the  CVE  is  useful  from  providing  standardized  names  for  vulnerabilities  and  of 
identifying  potential  vulnerabilities  or  exposures  in  systems,  it  provides  very  little,  if 
any,  detail  on  those  vulnerabilities  (Figure  4).  To  get  that  additional  information, 
system  administrators  will  have  to  use  other  resources,  such  as  ICAT  (described  in 
the  next  section). 


CVE- 1999-0308 


HP-UX  gwind  program  allows  users  to  modify  arbitrary  files. 

Reference:  HP:HPSBUX9410-018 
Reference:  XF:hpux-gwind-overwnte 
Reference:  C1ACH-03:  HP-UX  suid  Vulnerabilities 


CVE-1999-0309 


HP-UX  vgdisplay  program  gives  root  access  to  local  users. 

Reference:  HP:HPSBUX9702-056 
Reference:  XF:hpux-vgdisplay 

Reference:  C1AC  H-27:  HP-UX  vgdisplay  Buffer  Overrun  Vulnerability 


Figure  4  —  CVE  Search  Results 
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ICAT 


The  National  Institute  of  Standards  and  Technology  (NIST)  ICAT  Metabase  is  a 
searchable  index  of  computer  vulnerabilities.  It  links  users  to  a  variety  of  publicly 
available  vulnerability  databases  and  patch  sites,  thus  enabling  administrators  to 
find  and  fix  the  vulnerabilities  existing  on  their  systems.  In  this  way,  the  ICAT 
Metabase  takes  the  CVE  list  to  the  next  level  by  including  detailed  information  on 
each  vulnerability  or  security  exposure  contained  in  the  CVE  and  CVE  Candidate 
lists.  ICAT  is  not  a  vulnerability  database,  but  a  searchable  index  leading  users  to 
vulnerability  resources  and  patch  information  on  other  participating  websites.  ICAT 
allows  one  to  search  at  a  fine  granularity,  a  feature  unavailable  with  most 
vulnerability  databases,  by  characterizing  each  vulnerability  by  more  than  40 
attributes  (e.g.,  software  name,  version  number,  vulnerability  exploited). 

ICAT  indexes  information  from  the  following  sources: 

•  CERT  advisories 

•  ISS  X-Force 

•  Security  Focus 

•  NT  Bugtraq 

•  Bugtraq 

•  Various  other  patch  sites. 

ICAT  does  not  compete  with  publicly  available  vulnerability  databases,  but  instead 
is  a  search  engine  that  drives  traffic  to  them.  ICAT  uses  and  is  completely  based 
on  the  CVE  vulnerability  naming  standard  (see  previous  section). 

ICAT  is  updated  as  the  CVE  is  updated  generally  every  2  to  4  weeks.  The  ICAT 
vulnerability  analysts  examine  and  publish  all  of  the  CVE  entries  and  candidates 
within  1  week  of  their  being  announced  by  the  CVE  Standards  Committee.  Thus, 
there  is  a  minor  lag  between  the  time  a  vulnerability  is  discovered  and  the  time  it 
appears  on  the  ICAT  website. 

In  addition  to  being  accessible  by  web-based  search,  ICAT  can  also  be  downloaded 
in  a  variety  of  formats,  including  Microsoft  Access  2000.  This  allows  administrators 
to  conduct  searches  without  using  the  Internet  and  to  integrate  ICAT  into  their  own 
applications.  This  standalone  ICAT  can  be  downloaded  from 
http://icat.nist.aov/icat.cfm?function=download. 

In  conjunction  with  NIST,  CERIAS  at  Purdue  University  distributes  a  vulnerability 
notification  product  named  Cassandra  that  is  based  on  ICAT.  Cassandra  allows 
an  administrator  to  enter  the  names  and  versions  of  the  software  used  on  his  or  her 
computers  and  networks  into  a  database.  Cassandra  will  then  send  the 
administrator  e-mails  about  new  CVE  entries  and  candidates  that  meet  the 
administrator’s  software  profile.  Unlike  the  alerts  sent  by  many  advisory  systems 
which  may  or  may  not  be  applicable  to  an  administrator,  almost  every  vulnerability 
notification  sent  by  this  service  will  represent  a  vulnerability  in  the  software  that  the 
administrator’s  organization  employs.  Further,  using  their  Cassandra  interface, 
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administrators  can  search  ICAT  based  on  their  software  profile.  Since  Cassandra 
stores  the  products  the  administrator  uses,  this  eliminates  having  to  search  ICAT 
separately  for  each  product  every  time  he  or  she  needs  to  check  for  new 
vulnerabilities.  More  information  on  Cassandra  including  configuration  can  be 
found  at  https://cassandra.cerias.purdue.edu/main/index.html. 

Detailed  instructions  on  using  the  web-based  ICAT  are  provided  in  Appendix  B  of 
this  document. 

Vulnerability  Databases 

Even  though  ICAT  conducts  the  most  extensive  search  of  different  vulnerabilities 
provided  by  a  single  search  engine,  the  lag-time  inherent  in  the  CVE  naming 
process  may  require  administrators  to  use  one  the  many  public  available 
vulnerabilities  databases  as  well.  An  extensive  list  of  these  databases  is  provided  in 
Appendix  C,  and  hyperlinks  to  several  of  these  sites  are  provided  in  the  ICAT 
Metabase. 

These  sites,  generally  run  by  third  parties  not  affiliated  with  the  software  vendors, 
can  provide  a  wealth  of  information  to  system  administrators  and  security 
professionals.  They  generally  strive  to  cover  most  operating  systems  and  software 
applications.  Because  they  are  not  affiliated  with  software  vendors  they,  often 
provide  information  that  the  vendor,  or  other  organizations  affiliated  with  the  vendor, 
may  not  provide. 

These  sites  tend  to  be  the  quickest  to  report  new  vulnerabilities,  which  is  both  a 
benefit  and  a  disadvantage.  On  the  one  hand,  they  provide  timely  information  on 
vulnerabilities  which  is  critical  to  the  success  of  a  system  administrator  in  defending 
his  or  her  network.  On  the  other  hand,  the  site  do  not  provide  the  organized  vetting 
of  vulnerabilities  that  occurs  with  the  CVE  and  ICAT.  This  deficiency  means  the 
same  vulnerability  may  be  reported  more  than  once  dramatically  increasing  the 
chance  of  false  reports. 

Although  the  amounts  and  type  of  information  vary  to  some  degree  from  site  to  site, 
sites  generally  include  the  following  types  of  information: 

•  News— General  information  system  security  articles  that  provide  system 
administrators  and  security  professionals  with  the  background  information 
they  may  find  useful  by  providing  articles  and  news  on  all  aspects  of 
information  security.  The  news  section  often  includes  information  on 
ongoing  or  predicted  threats  including: 

o  Malicious  code  (virus,  worms,  and  Trojans) 

o  Hacktivisim  (hacking  to  advance  a  political  or  economic  agenda 
often  associated  with  website  defacement) 

o  Other  kinds  of  new  remote  attacks  and  attack  techniques  not 
specifically  related  to  a  vulnerability. 

•  Basics  or  Introduction — Provides  introductory  information  on  networking 
and  information  system  security.  Useful  to  administrators  who  need  some 
background  in  systems  security. 
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Vulnerability  Database — Provides  information  on  known  vulnerabilities 
and  patches,  and  generally  includes  most  of  the  following. 


o  Vulnerability  Overview — This  general  includes  a  introduction  to  the 

vulnerability  that  generally  includes. 

■  CVE  Number — Number  assigned  by  CVE,  if  applicable 

■  Classification — Type  of  vulnerability  (buffer  overflow, 
design  error,  etc.) 

■  Date  of  First  Publication — Date  the  vulnerability  was  first 
publicly  identified 

■  Date  of  Last  Update  or  Revision — Date  the  vulnerability  or 
patch  information  was  last  updated 

■  Vulnerable  Systems — The  operating  system,  application, 
or  hardware  affected  by  the  vulnerability. 

o  Discussion  or  Analysis — More  detailed  information  on  the 
vulnerability.  Information  can  be  range  in  length  from  one 

paragraph  to  several  pages  depending  on  the  complexity  of  the 
vulnerability  and  can  be  highly  technical. 

o  Solution — A  detailed  discussion  on  mitigating  or  eliminating  the 

vulnerability.  Generally  contains  hyperlinks  to  the  pertinent 

vendor’s  website  for  patches  and  updates.  If  applicable,  will  also 
include  other  mitigation  techniques.  May  also  discuss  any 
negative  impacts  of  the  vendor’s  patch,  if  applicable. 

o  Exploit3 — Includes  information  on  exploiting  the  vulnerability  and 

any  applicable  software  code.  May  also  contain  links  to  the  other 
sites  that  have  more  information  and  exploit  code.  This 
information  can  be  useful  to  the  administrator  in  testing  whether 
his  or  her  system  is  susceptible  to  exploitation  (before  or  after  the 
patch  is  applied).  However  great  care  should  be  exercised  in 
using  these  techniques. 

o  Credit — Recognizes  those  who  identified  the  vulnerability,  created 

the  exploit,  or  otherwise  provided  information  or  assistance.  Often 
contains  hyperlinks  to  the  website(s)  of  the  contributor(s). 

Overall  vulnerability  databases  are  one  of  the  most  powerful  weapons  in  the  system 
administrator’s  arsenal.  Even  if  an  administrator  relies  principally  on  other  sources 
for  vulnerability  information,  the  general  news  and  discussions  provided  on  the 
vulnerability  database  sites  can  prove  invaluable. 


3  Exploits  are  documented  procedures,  programs,  and/or  scripts  that  take  advantage  of  vulnerabilities. 
Many  vulnerability  databases  provide  exploit  instructions  or  code  for  most  identified  vulnerabilities.  Exploit 
programs  or  scripts  are  actually  just  specialized  software  tools  for  exploiting  a  specific  vulnerability. 
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Other  Methods  of  Vulnerability  Identification 
Vulnerability  Scanners 

Vulnerability  scanners  are  commonly  used  in  many  organizations  to  identify 
vulnerabilities  on  their  organization’s  hosts  and  networks.  A  vulnerability  scanner 
automatically  identifies  not  just  hosts  and  open  ports  but  any  associated 
vulnerabilities.  It  will  identify  a  host’s  operating  system  and  active  applications  and 
then  compare  these  to  its  database  of  known  vulnerabilities.  Vulnerability  scanners 
employ  large  databases  of  vulnerabilities  to  identify  vulnerabilities  associated  with 
commonly  used  operating  systems  and  applications.  When  a  match  is  found  the 
scanner  will  alert  the  operator  to  a  possible  vulnerability.  Most  vulnerability 
scanners  also  provide  information  on  how  to  mitigate  discovered  vulnerabilities. 

They  can  also  help  identify  out-of-date  software  versions  and  applicable  patches  or 
system  upgrades.  And  can  also  validate  compliance  with,  or  deviations  from,  the 
organization's  security  policy.  In  addition,  vulnerability  scanners  can  automatically 
make  corrections  and  fix  certain  discovered  vulnerabilities.  (This  assumes  that  the 
operator  of  the  vulnerability  scanners  has  “root”  or  administrator  access  to  the 
vulnerable  host.) 

Vulnerability  scanners  provide  system  and  network  administrators  with  tools  that 
can  be  used  to  proactively  identify  and  address  vulnerabilities  before  an  adversary 
discovers  them.  A  vulnerability  scanner  is  a  relatively  fast  and  easy  way  to  quantify 
an  organization's  exposure  to  surface  vulnerabilities.4 

However  vulnerability  scanners  have  some  significant  weaknesses.  Generally,  they 
identify  only  surface  vulnerabilities  and  are  unable  to  address  the  overall  risk  level  of 
a  scanned  network.  The  scan  process  itself  is  highly  automated  however,  because 
vulnerability  scanners  can  have  a  high  false  positive  error  rate  (reporting 
vulnerabilities  when  none  exist),  an  ndividual  with  expertise  in  networking  and 
operating  system  security  and  administration  must  interpret  the  results. 

Vulnerability  scanners  can  generate  significant  amounts  of  network  traffic.  This 
may  have  a  negative  impact  on  the  hosts  or  network  being  scanned  or  on  the 
network  segments  the  scanning  traffic  is  traversing.  Many  vulnerability  scanners 
also  include  tests  for  denial-of-service  (DoS)  attacks  that,  in  the  hands  of  an 
inexperienced  user,  can  have  a  considerable  negative  impact  on  scanned  hosts. 

Another  significant  limitation  of  vulnerability  scanners  is  that  their  ability  to  recognize 
the  latest  vulnerabilities  depends  on  the  constant  updating  of  the  scanner’s 
vulnerability  database.  Before  running  any  scanner  an  administrator  must  be  sure 
to  install  the  latest  updates  to  its  vulnerability  database.  Some  vulnerability  scanner 
databases  are  updated  more  regularly  than  others  (frequency  of  updates  should  be 
a  major  consideration  in  choosing  a  vulnerability  scanner). 


4  A  surface  vulnerability  is  a  weakness  as  it  exists  in  isolation,  that  is  without  any  other  vulnerability.  The 
difficultly  of  identifying  the  risk  level  of  vulnerabilities  is  that  they  rarely  exist  in  isolation.  For  example,  there 
could  be  several  “low  -risk”  vulnerabilities  on  a  particular  network  that,  when  combined,  present  a  high  risk. 
A  vulnerability  scanner  would  generally  not  recognize  the  danger  of  the  combined  vulnerabilities  and  thus 
would  assign  a  low  risk  Id  each  leaving  the  network  administrator  with  a  false  sense  of  confidence  in  his  or 
her  security  measures.  The  reliable  way  to  identify  the  risk  of  vulnerabilities  in  aggregate  is  through 
penetration  testing.  For  more  information  on  network  testing  see  NST  Special  Publication  SP-XX, 
Information  System  Security  Testing  Overview. 
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Vulnerability  scanners  are  better  at  detecting  well-known  vulnerabilities  than  they 
are  at  finding  more  esoteric  ones.  This  is  due  to  fact  that  it  is  impossible  for  any  one 
product  to  incorporate  all  known  vulnerabilities  in  a  timely  manner.  In  addition, 
manufacturers  may  elect  not  include  every  possible  vulnerability,  to  keep  the  speed 
of  their  scanners  high  (more  vulnerabilities  detected  requires  more  tests  which 
slows  the  overall  scanning  process). 

Vulnerability  scanners  provide  the  following  capabilities: 

•  Identifying  active  hosts  on  network 

•  Identifying  active  and  vulnerable  services  (ports)  on  hosts 

•  Identifying  vulnerabilities  associated  with  discovered  operating  systems 
and  applications 

•  Testing  compliance  with  host  application  usage/security  policies. 

Vulnerability  scanners  can  be  of  two  types:  network  scanners  and  host  scanners. 
Network  scanners  are  used  primarily  to  map  an  organization's  network  and  identify 
open  ports.  In  most  cases,  these  scanners  are  not  limited  by  the  operating  system 
of  targeted  systems.  They  can  be  installed  on  a  single  system  on  the  network  and 
can  quickly  locate  and  test  numerous  hosts.  Host  scanners  on  the  other  hand, 
must  be  installed  on  each  host  to  be  tested.  These  scanners  are  used  primarily  to 
identify  specific  host  operating  system  and  application  misconfigurations  and 
vulnerabilities.  Host  scanners  have  high  detection  granularity  and  usually  require 
not  only  host  (local)  access  but  also  a  root  or  administrative  account.  Some  host 
scanners  offer  the  capability  of  repairing  any  misconfigurations. 

Organizations  should  conduct  vulnerability  scanning  to  validate  that  operating 
systems  and  major  applications  are  up  to  date  on  security  patches  and  software 
version. 

Vulnerability  scanning  results  should  be  documented,  and  discovered  deficiencies 
corrected.  The  following  corrective  actions  may  be  a  necessary  follow-on  to 
vulnerability  scanning: 

•  Upgrade  or  patch  vulnerable  systems  to  mitigate  identified  vulnerabilities  as 
appropriate 

•  Deploy  mitigating  measures  (technical  or  procedural)  if  system  cannot  be 
immediately  patched  (e.g.,  if  application  system  upgrade  will  make  the 
application  running  on  top  of  the  operating  system  inoperable)  to  minimize 
the  probability  of  the  system  is  being  compromised 

•  Tighten  configuration  management  program  and  procedures  to  ensure  that 
systems  are  upgraded  routinely 

•  Modify  the  organization's  security  policies,  architecture,  or  other 
documentation  to  ensure  that  security  practices  include  timely  system 
updates  and  upgrades. 
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Network  and  host-based  vulnerability  scanners  are  available  for  free  or  for  a  fee. 
Appendix  D  contains  a  list  of  readily  available  vulnerability  scanning  tools  and  a 
simple  example  of  scanner  use. 

Vulnerability  Advisories 

Certain  websites  issue  ad  hoc  advisories  for  specific  vulnerabilities  and  threats  that 
exceed  a  particular  threshold  or  magnitude.  By  addressing  not  only  patches  and 
vulnerabilities  but  also  threats,  these  sites  go  beyond  the  other  resources  discussed 
so  far.  These  advisories  can  be  of  great  help  to  a  system  administrator.  The  two 
primary  sources  for  these  types  of  advisories  are  the  Federal  Bureau  of 
Investigation's  (FBI)  National  Infrastructure  Protection  Center  (NIPC)  and  Carnegie 
Mellon  University's  CERT. 

NIPC 

Established  in  February  1998,  the  NIPC  serves  as  the  U.S.  Government's  focal 
point  for  threat  assessment,  warning,  investigation,  and  response  concerning 
threats  or  attacks  against  critical  network  infrastructures.  The  center  is  a  joint 
Government  and  private-sector  partnership  that  includes  representatives  from  the 
relevant  federal,  state,  and  local  government  agencies  as  well  as  representatives  of 
relevant  commercial  organizations. 

The  NIPC  produces  three  levels  of  infrastructure  warnings,  which  are  developed 
and  distributed  in  accordance  with  the  FBI's  National  Threat  Warning  System. 
Collectively,  these  “threat  warning”  products  are  based  on  material  that  is 
significant,  credible,  and  timely,  and  that  addresses  cyber  and/or  infrastructure 
dimensions  with  possibly  significant  impact.  These  warnings  will  often  be  based  on 
classified  material  and  include  dissemination  restrictions,  but  NIPC  will  generally 
produce  a  “sanitized”  unclassified  version  for  public  use. 

The  three  levels  NIPC  of  threat  warnings: 

•  Assessments — The  lowest  level  of  warning.  These  address  broad, 
general  incident  or  issue  awareness  information  and  analysis  that  are  both 
significant  and  current,  but  that  does  not  necessarily  suggest  immediate 
action. 

•  Advisories— These  address  significant  threat  or  incident  information  that 
suggests  a  change  in  readiness  posture,  protective  options  and/or 
response. 

•  Alerts — The  highest  level  of  warning.  These  address  major  threat  or 
incident  information  concerning  imminent  or  in-progress  attacks  targeting 
specific  national  networks  or  critical  infrastructures. 

Links  to  these  warnings  can  be  found  on  the  NIPC  website  at 
http://www.nipc.aov/warninas/warninas.htm.  A  partial  sample  of  a  NIPC  alert  is 
provided  in  Figure  5. 
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"Code  Red  Worm" 

July  29.  2001 


A  Very  Redl  and  Piesenl  Thieal  to  the  Internal:  July  31  Deadline  Foi  Action 

Summary:  The  Code  Red  Worm  and  mutations  of  the  worm  pose  a  continued  and  serious 
threat  to  Internet  users  Immediate  action  is  required  to  combat  this  threat  Users  who  have 
deployed  software  that  is  vulnerable  to  the  worm  (Microsoft  IIS  Versions  4  0  and  5  0)  must  install,  if 
they  have  not  done  so  already,  a  vital  security  patch 

How  Big  Is  The  Problem?  On  July  19,  the  Code  Red  worm  infected  more  than  250,000  systems  in 
just  9  hours  The  worm  scans  the  Internet,  identifies  vulnerable  systems,  and  infects  these  systems 


Figure  5  —  Sample  NIPC  Alert 


CERT 

The  CERT  Coordination  Center  (CERT/CC)  is  a  center  of  Internet  security 
expertise,  at  the  Software  Engineering  Institute,  a  federally  funded  research  and 
development  center  operated  by  Carnegie  Mellon  University.  The  CERT/CC  was 
established  in  November  1988,  after  a  Cornell  University  graduate  student  released 
the  Morris  worm,  which  brought  down  much  of  the  Internet  and  demonstrated  the 
growing  network's  susceptibility  to  attack. 

CERT  responds  to  major  vulnerabilities  and  threats  by  issuing  advisories  which  can 
be  found  at  http://www.cert.org/advisories/.  Here  users  will  find  all  CERT  advisories 
dating  back  to  the  inception  of  CERT  in  1988.  Advisories  are  organized  by  year 
and  then  sequentially  numbered.  For  example  the  first  advisory  for  2001  is 
numbered  CA-2001-01  (CA  =  CERT  Advisory,  2001  =  year  and  01  =  1st  advisory  of 
the  year). 

Several  methods  are  provided  for  identifying  relevant  advisories  on  the  CERT  site: 
searching  for  keywords  using  the  CERT  search  engine,  accessing  the  CERT 
advisories  page  and  selecting  the  appropriate  year  (which  will  list  summaries  of  all 
advisories  for  a  given  year),  and  accessing  the  CERT  Current  Activity  web  page  at 
http://www.cert.org/advisories/  (which  provides  a  list  “of  the  most  frequent,  high- 
impact  types  of  security  incidents  and  vulnerabilities  currently  being  reported  to  the 
CERT”  [see  Figure  6]). 
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Figure  6  —  CERT  Current  Activity  Page 


Each  CERT  advisory  provides  significant  amount  information  to  assist  the  system 
administrator  and  security  professional.  The  advisories  are  also  updated  as  new 
information  is  discovered  and  patches  become  available.  Each  advisory  begins 
with  a  title,  the  advisory’s  original  release  date,  and  date  of  last  revision.  After  this 
introductory  information,  the  advisory  is  divided  into  several  major  sections  that  help 
a  system  administrator  identify  and  mitigate  vulnerabilities  and  apply  patches. 


•  Systems  Affected — Provides  a  list  of  software  and/or  hardware  affected 
by  the  vulnerability 

•  Overview — Provides  a  brief  description  of  the  vulnerability 

•  Description — Presents  a  detailed  analysis  of  the  vulnerability  and 
provides  hyperlinks  to  additional  sources  of  information 

•  Impact — Describes  the  possible  effects  of  a  successful  exploitation 

•  Solution — Provides  information  on  correcting  the  problem,  including 
patches,  if  available. 


Windows  Update 


Microsoft’s  Windows  Update  website  is  one  attempt  to  simplify  the  update 
notification  and  installation  process.  In  essence,  Windows  Update  is  an  on-line 
extension  of  Windows.  Currently  Windows  Update  has  two  separate  sections:  the 
Product  Updates  catalog  and  the  Support  Information  area. 

The  Product  Updates  area  is  a  catalog  of  fixes,  updates,  and  enhancements  to 
Windows  and  many  programs  that  are  included  with  Windows  (e.g.,  Internet 
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Explorer  and  Media  Player).  It  allows  users  to  select  updated  or  new  components 
to  add  to  their  Windows  installation,  including  security  patches. 

Users  can  select  as  many  components/updates  as  they  require  and  download  and 
install  them  straight  from  the  web  to  their  computers.  More  specifically,  when  a  user 
first  accesses  the  Product  Updates  page,  Windows  Update  scans  his  or  her  system 
to  ascertain  the  system’s  characteristics  (including  Windows  version,  service  pack 
level,  applications  installed).  This  scan  is  performed  without  sending  any 
information  to  Microsoft  or  over  the  Internet.  After  Windows  Update  has  determined 
the  exact  parameters  of  the  Windows  installation  on  the  user’s  computer,  it  creates 
a  personalized  catalog  of  available  updates. 

When  this  catalog  page  appears,  users  can  select  the  updates  he  or  she  requires. 
Users  should  download  any  Critical  Updates  recommended  for  their  system  since 
these  will  rectify  known  problems  (often  performance  or  security  issues).  More 
information  on  using  Windows  Update  is  provided  in  Appendix  E. 

The  Support  Information  area  of  the  Windows  Update  site  provides  additional 
information  and  assistance  on  updating  and  patching  Microsoft  Windows  systems. 
It  contains  sections  on  frequently  asked  questions,  known  issues  and  contact 
information  for  Microsoft  support.  It  also  provides  links  to  other  Microsoft  sites  that 
support  Microsoft  products  not  yet  supported  by  Windows  Update  (e.g.,  Exchange 
Server,  SQL  Server). 
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Patching  Procedures 


Obtaining  Patches 

As  discussed  previously  the  most  important  step  in  maintaining  an  up-to-date 
system  is  identifying  and  installing  the  patches  or  updates  available  for  a  system  or 
the  applications  running  on  that  system.  Although  vendor  websites  should  always 
have  the  most  up  to  date  patch  information  for  their  software,  they  are  not  always 
the  easiest  means  of  keeping  up  to  date.  For  example,  it  is  difficult  for 
administrators  in  heterogeneous  environments  to  frequently  visit  multiple  websites. 
For  this  reason,  many  third-party  security  sites  have  emerged  that  maintain 
databases  for  identifying  available  patches.  These  databases  can  be  searched  for 
the  particular  software  or  operating  systems  employed  at  the  administrator’s  site. 
The  results  usually  contain  information  about  the  vulnerabilities  associated  with  the 
specified  software  and  system  along  with  links  to  vendor  sites  with  the  patch 
information  or  downloads. 

Although  third-party  websites,  mailing  lists,  and  newsgroups  are  often  one  of  the 
first  places  where  information  on  a  new  vulnerability  becomes  available  and  can  be 
useful  for  identifying  patches,  they  generally  should  not  be  used  to  download 
patches.  Administrators  should  generally  be  very  suspicious  of  patches  from  third 
parties.  Certain  third-party  website,  mailing  lists  and  newsgroups  are  notorious 
distribution  points  for  a  variety  of  malicious  programs.  These  programs  are  often 
advertised  as  an  official  patch  or  tool  for  correcting  a  known  vulnerability  when  in 
fact  they  are  just  a  backdoor  distributed  by  hackers  in  an  attempt  to  compromise  or 
otherwise  identify  vulnerable  systems.  Generally,  patches  should  only  be 
downloaded  from  the  vendor  or  other  trusted  source. 

An  illustration  of  malicious  code  distribution  in  this  manner  involves  the  “removal” 
programs  for  the  Windows  Trojan  backdoor,  Back  Orifice.  The  two  programs  are 
BOSniffer  and  BODetect.  One  of  these  programs,  BODetect,  actually  does  detect 
and  remove  Back  Orifice;  the  other  program,  BOSniffer,  is  actually  an  install 
program  for  Back  Orifice. 

Patching  Precautions 

Whatever  the  source  of  the  patch,  a  system  administrator  should  take  several 
precautions  before  attempting  installation.  First,  most  vendors  today  provide  some 
type  of  authentication  mechanism.  The  downloaded  patch  should  be  checked 
against  any  of  the  authenticity  methods  the  vendor  provides. 

•  Verify  Cryptographic  Checksums — usually  Message  Digest  (MD)  5 
checksum) 

•  Verify  PGP  signatures 

•  Verify  Digital  Certificate 

Some  of  these  methods,  such  as  verifying  digital  signatures,  are  highly  automated, 
requiring  little  user  interaction.  Others,  such  as  MD5  checksum,  require  the  user  to 
visit  the  vendor's  website  to  check  the  MD5  checksum  listed  there  against  the 
downloaded  patch.  Although  these  methods  add  an  additional  level  of 
authentication,  they  are  not  foolproof.  For  example,  hackers  have  obtained  digital 


22 


signatures  in  the  past  that  have  provided  them  with  the  ability  to  distribute  patches 
in  the  name  of  a  major  software  company.  Although  this  was  just  a  proof  of  concept 
and  the  hackers  did  not  attempt  to  exploit  the  fake  digital  signatures,  they  easily 
could  have.  The  bottom  line  is  authentication  is  no  substitute  for  common  sense. 

A  virus  scan  should  also  be  run  on  all  patches  before  installation.  Before  running 
the  scan,  the  administrator  should  ensure  that  the  virus  signature  database  in  the 
anti-virus  program  is  up  to  date.  Again  this  system  is  not  foolproof  since  if  some 
hacker  has  created  an  entirely  new  Trojan  and  included  it  with  the  patch,  it  might  not 
be  detected  by  the  virus  program. 

If  the  patch  is  not  distributed  compiled  (that  is  if  the  user  must  compile  the  source 
code  prior  to  installation)  the  administrator  should  perform  a  code  review  before 
compiling  and  installation.  This  is  a  common  situation  for  the  patches  of  Linux  and 
some  Unix  operating  systems.  If  an  administrator  is  not  comfortable  performing  the 
code  review  he  or  she  should  use  an  expert  who  is,  or  ensure  that  the  source  code 
is  download  from  a  trusted  site. 

Before  installing  the  patch  and  especially  if  they  do  not  have  the  time  or  resources 
to  perform  a  test  on  the  patch  before  employing  it  on  a  production  system, 
administrators  should  find  out  what  experiences  others  have  had  in  installing  or 
using  the  patch.  For  instance,  the  administrator  should  attempt  to  learn  whether 
other  have  experienced: 

•  Patch  does  not  correct  the  vulnerability 

•  Patch  opens  an  old  vulnerability 

•  Patch  creates  a  new  vulnerability 

•  Patch  reduces  reliability 

•  Patch  reduces  performance 

•  Patch  is  incompatible  with  other  required  applications. 

If  one  or  more  of  the  above  problems  applies,  the  administrator  will  need  to  consider 
whether  the  disadvantages  outweigh  the  benefits  of  installing  the  patch.  If  installing 
the  patch  is  not  critical,  it  may  be  better  to  wait  until  the  vendor  releases  a  newer 
patch  that  corrects  the  major  issues  (this  is  a  common  occurrence).  The  more 
complex  the  patch  (the  file  size  of  the  patch  gives  some  indication  of  complexity)  the 
more  likely  one  or  more  of  the  issues  above  will  arise.  For  example,  a  Microsoft 
Windows  hotfix  (usually  just  a  single  patch)  is  much  less  likely  to  cause  problems 
than  a  service  pack  that  contains  a  large  number  of  fixes.  Also,  the  ability  to  “undo" 
or  uninstall  a  patch  should  be  considered  although,  even  when  this  option  is 
provided,  the  uninstall  process  does  not  always  return  the  system  to  its  previous 
state. 

Another  consideration  that  needs  to  be  taken  into  account  is  the  frequency  of  patch 
releases.  For  example,  during  the  first  nine  months  of  2001,  Microsoft  alone 
released  49  security  bulletins  with  as  many  as  7  bulletins  released  in  1  month.  In 
the  year  2000,  Microsoft  released  100  security  bulletins,  releasing  as  many  as  13 
bulletins  in  1  month.  Thus,  patching  could  easily  become  a  full  time  job  for  an 
administrator. 
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Before  applying  a  patch,  an  administrator  and  management  must  consider. 


•  Cost  of  deploying  one  patch  versus  cost  of  deploying  a  bundle  of  patches 

•  Automated  versus  manual  deployment 

•  Whether  the  patch  can  be  consistently  deployed  throughout  all  vulnerable 
systems. 

If  the  decision  is  made  to  gather  several  patches  together  and  combine  the 
deployment,  there  are  additional  considerations: 

•  Risks  associated  with  delaying  installation  of  one  or  more  patches  so  that  a 
few  may  be  bundled  together 

•  Complications  arising  from  combining  patches 

•  Possibility  that  installing  several  patches  at  once  will  complicate 
troubleshooting  (e.g.,  which  patch  caused  the  problem?);  this  potential 
needs  to  be  weighed  against  the  time  saved  in  instillation. 

The  risk  of  delaying  the  application  of  patches,  particularly,  must  be  carefully 
weighed.  For  example,  when  the  vulnerability  that  was  eventually  exploited  by  the 
Code  Red  worm  was  discovered,  because  there  was  no  immediate  danger  many 
administrators  delayed  installing  the  patch.  However,  within  a  month  a  very  virulent 
worm  (Code  Red)  was  released  that  exploited  many  of  the  unpatched  systems.  In 
weighing  the  risk  of  delay  against  the  labor-saving  benefit  of  combining  patches,  the 
following  issues  must  be  considered: 

•  Threat  Level — Does  the  organization  or  computer(s)  requiring  patching 
face  numerous  and/or  significant  threats?  For  example,  public  web  servers 
and  most  Federal  Government  organizations  face  fairly  high  threat  level. 
Generally  speaking,  for  these  systems,  timely  patching  is  critical.  In 
contrast  for  an  internal  intranet  site  that  is  inaccessible  from  the  Internet, 
patching  can  often  be  delayed,  since  such  a  site  faces  a  much  lower  threat 
level. 

•  Risk  of  Compromise — What  is  the  likelihood  that  a  compromise  will 
occur?  If  the  vulnerability  is  easy  to  exploit,  then  the  patch  should  be 
applied  promptly. 

•  Consequences  of  Compromise— What  are  the  consequences  of 
compromise?  If  the  system  is  critical  or  contains  sensitive  data  then  the 
patch  should  be  applied  immediately.  This  holds  true  even  for  non  critical 
systems  if  a  successful  exploitation  would  lead  to  “rooting”5  of  the  system. 


Unfortunately  neither  the  decision  apply  nor  the  chose  of  not  applying  a  patch  is  risk 
free.  The  correct  decision  is  not  always  clear  and  too  often  the  decision  made  is  to 
make  “no  decision”  which  generally  results  in  a  compromised  system.  System 
administrators  and  management  must  work  together  to  create  a  systematic  process 


5  "Rooting”  a  system  is  hacker  slang  for  gaining  administrative  or  root- level  access  to  a  target  system.  This 
means  the  attacker  has  full  control  over  the  attacked  system.  Any  vulnerability  that  could  lead  to  this  level 
of  access  should  be  corrected  or  patched  immediately. 
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for  evaluating  patches  and  determining  the  appropriate  decision  within  the  context 
of  their  organization. 

Testing  Patches 

Testing  of  patches  is  critical  for  several  reasons.  In  a  perfect  world,  all  patches 
would  be  widely  tested  before  release  and  would  work  flawlessly.  Unfortunately, 
matters  are  much  more  complicated.  As  previously  discussed,  bugs  are  in  all 
software,  and  patches  are  no  exception.  Many  patches  are  extremely  complicated 
and  contain  significant  amounts  of  code  (e.g.,  Microsoft  service  packs  are  often  10 
to  20  megabytes  apiece).  In  addition,  patches  are  often  released  in  haste,  in  order 
to  quickly  repair  a  vulnerability;  this  means  they  often  receive  less  testing  from  the 
vendor  than  did  the  original  software.  Thus,  for  all  of  these  reasons,  patches  can 
easily  produce  unintended  consequences.  It  may  be  possible  for  patches  that  do 
not  contain  a  bug  to  change  a  system  enough  to  cause  some  other  software 
component  or  application  to  fail. 

In  addition  to  the  need  to  identify  any  unintended  consequences,  patches  should  be 
tested  to  ensure  that  they  have  patched  the  vulnerability  or  corrected  the 
performance  issue  as  intended.  Administrators  should  never  assume  that  a  patch 
is  functioning  on  their  system  unless  they  have  tested  it  themselves.  This  issue  is 
complicated  by  the  fact  that  the  order  in  which  patches  are  applied  can  be  critical  to 
their  successful  operation.  It  is  quite  possible  to  undo  a  previous  patch  by  installing 
another  patch.  To  avoid  this  problem  it  is  critical  that  administrators  exactly  follow 
the  vendor’s  instructions  for  applying  all  patches  and  then  test  the  patches  after 
installation. 

Before  applying  a  patch  an  administrator  must  decide  whether  he  or  she  should 
install  the  patch  directly  on  a  production  or  install  it  on  a  development  system  or 
some  other  system.  This  issue  is  extremely  complicated  and  is  influenced  by 
number  of  issues,  including: 

•  Organization's  configuration  management  policies 

•  Seriousness  of  vulnerability 

•  Threat  level  of  system  with  vulnerability 

•  Ability  to  temporarily  mitigate  vulnerability  through  other  methods  (e.g., 
firewall  rules,  permission  changes,  etc.) 

•  Whether  there  is  an  appropriate  system  on  which  to  conduct  the  test 

•  Complexity  of  patch 

•  Complexity  of  production  system 

•  Number  of  systems  to  be  patched 

•  Experiences  of  others  in  installing  the  patch 

•  Vendor  guidance  (this  includes  all  vendors  whose  applications  are  running 
on  the  system[s]  to  be  patched) 
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•  Previous  experience  in  patching  the  systems  on  which  the  patch  will  be 
installed. 

Only  a  system  administrator,  in  conjunction  with  management,  can  make  the 
appropriate  determination  on  whether  to  perform  testing  on  a  development  system 
or  perform  it  on  the  production  system. 

Whether  the  administrator  decides  to  install  and  test  the  patch  on  a  development 
server  or  on  the  production  server  he  or  she  will  need  to  test  both  the  operation  of 
the  system  and  the  vulnerability  or  vulnerabilities  the  patch  addresses.  Once  the 
patch  has  been  installed  successfully  and  the  system  rebooted  (if  required),  the 
administrator  should  compare  the  performance  of  the  system  to  previous  baselines 
to  ensure  that  the  patch  has  not  affected  performance  negatively.  If  the  result  of 
that  test  appears  to  be  acceptable,  the  administrator  should  test  the  functionality  of 
the  system  and  ensure  the  system  is  operating  correctly.  If  that  test  is  completed 
successfully,  the  administrator  should  test  whether  the  vulnerability  has  been 
corrected.  This  can  be  accomplished  by  several  methods: 

•  Scan  host  with  vulnerability  scanner  capable  of  detecting  vulnerability 

•  Employ  exploit  procedures  or  code  and  attempt  to  exploit  the  vulnerability 
(i.e.,  perform  a  penetration  test) 

•  Check  that  the  files  or  configuration  settings  the  patch  was  intended  to 
correct  have  been  changed  as  documented  in  the  vendor’s  documentation. 

A  patch  installation  is  not  complete  until  the  system’s  functionality  and  the 
remediation  of  the  targeted  vulnerability  have  been  fully  tested  and  determined  to 
meet  the  organization's  requirements. 

Applying  Patches 

Patches  can  come  in  many  different  forms;  can  be  applied  by  just  a  simple  click 
from  a  web  browser  through  complex  operating  system  and  kernel-specific 
compilation  of  source  code.  Patching  of  vulnerability  may  be  as  simple  as  the 
modifying  a  configuration  setting,  or  may  require  the  installation  of  a  completely  new 
version  of  the  software.  There  is  no  simple  patch  application  methodology  that 
applies  to  all  software  and  operating  systems. 

Each  vendor  of  an  operating  system  and  application  will  have  specific — often- 
unique — methodology  for  patching  and  updating  its  product.  For  this  reason,  it  is 
recommended  that  the  administrator  read  all  relevant  documentation  provided  by 
the  vendor.  The  tools  or  utilities  used  to  assist  and/or  automate  this  process  (see 
Appendixes  E  through  G)  may  also  vary  from  vendor  to  vendor.  The  guidance 
provided  in  this  document  is  not  intended  as  a  substitute  for  the  documentation  and 
recommendations  of  the  product  vendors. 

Updating  Linux/Unix  Operating  Systems  and  Applications 

Within  a  Linux  or  Unix  system,  many  methods  are  available  for  installing  a  patch  or 
update,  depending  on  the  particular  operating  system  and  version.  The  process 
usually  involves  compiling  the  source  code  for  the  patches  for  the  specific  operating 
system  and  kernel  version  in  use.  On  certain  installations,  the  order  in  which  the 
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patches  are  applied  may  be  important,  in  addition  to  location  in  the  directory  tree 
where  the  installation  updates  should  occur. 

Certain  distributions  also  have  additional  utilities  that  should  be  used  to  install  a 
patch  or  update.  Due  to  the  large  variance  in  procedures  for  applying  a  patch  from 
the  distributions,  the  user  should  consult  the  vendor  and  distribution-specific  user 
manuals  for  more  detailed  instructions.  References  for  common  Linux  and  Unix 
distributions  can  be  found  in  Appendix  A. 

Updating  Network  Infrastructure  Components 

Network  infrastructure  components  (e.g.,  routers,  firewalls,  switches,  IDS  etc.)  are 
some  of  the  most  critical  systems  to  keep  patched.  There  are  many  different 
methods  available  for  patching  or  updating  these  systems  depending  on 
component  type  and  manufacturer.  The  process  generally  involves  obtaining  the 
software  from  the  appropriate  vendor  and  following  their  specific  instructions  for 
installing  it. 

A  few  components  of  the  network  infrastructure  require  special  consideration  when 
patching.  Border  routers  and  firewalls  as  an  organization’s  first  line  of  defense 
should  be  updated  as  soon  as  there  is  a  known  vulnerability.  A  compromise  of  one 
these  systems  could  lead  to  the  compromise  of  the  entire  network.  There  is  at  best 
minimal  time  (hours  to  days)  to  test  the  patch  or  update  prior  to  application,  as 
attacks  attempting  to  exploit  these  vulnerabilities  are  likely  to  be  occurring  as  soon 
as  the  vulnerability  is  discovered. 

Virus  detection  programs  that  are  installed  on  the  firewall,  e-mail  servers  and  file 
servers  need  to  be  updated  very  frequently.  Anti-virus  programs  rely  on  a  database 
of  virus  signatures  to  recognize  a  vi  rus.  If  this  database  is  not  up  to  date  then  the 
program  cannot  recognize  newer  viruses  that  generally  represent  the  greatest 
threat.  These  updates  should  occur  at  a  minimum  on  a  weekly  basis  and  on  an  ad 
hoc  basis  when  a  particularly  virulent  new  virus  is  traversing  the  Internet.  Failure  to 
update  these  anti-virus  programs  could  result  in  the  widespread  distribution  of  one 
or  more  viruses  within  an  organization. 

Intrusion  detection  systems,  similar  to  anti-virus  programs  rely  on  a  database  of 
attack  signatures  to  recognize  attacks.  Since  new  attack  techniques  are  being 
developed  all  the  time,  updating  this  database  is  critical  to  the  ability  of  the  IDS  to 
detect  and  report  attacks. 

Updating  Windows  Operating  Systems  and  Applications 

There  are  many  methods  for  applying  patches  for  Windows  and  Windows -based 
software.  Most  version  of  Windows  and  many  programs  now  have  simple  “update” 
buttons  that  when  clicked  automatically  access  the  Internet  and  check  for  an 
update,  and,  if  one  is  available,  download  and  install  it.  This  type  of  automated 
feature  can  be  of  great  assistance  to  administrators.  If  no  automatic  update  feature 
is  built  into  the  software,  the  administrator  will  have  to  manually  monitor  for  updates 
using  the  procedures  described  previously.  Even  when  automated  procedures  are 
available,  many  administrators  prefer  to  manually  install  patches  because  this 
generally  gives  them  greater  control  over  the  process.  This  is  largely  a  matter  of 
personal  preference,  with  either  option  having  both  pros  and  cons. 

To  assist  updating  its  operating  systems  and  certain  applications,  Microsoft  has 
created  a  variety  of  tools  and  automated  techniques  to  identify  necessary  patches 
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and  install  them.  These  tools  are  relatively  new,  and  additional  functionality  is  being 
added  on  a  continual  basis.  As  of  the  writing  of  this  document,  Microsoft  offered  the 
following  capabilities: 

•  Windows  Update — This  allows  an  administrator  to  scan  his  or  her 
computer(s)  to  find  operating  system  updates  available  through  Microsoft. 
This  scan  will  identify  any  hotfixes  or  security  patches  that  are  needed  in 
addition  to  listing  other  software  updates  that  are  available.  See  Appendix 
E  for  more  information  about  Windows  Update. 

•  Microsoft  Office  Update — Like  Windows  Update,  this  allows  an 
administrator  to  scan  his  or  her  computer(s)  to  find  Office  updates  available 
through  Microsoft. 

•  Microsoft  Personal  Security  Advisor  (MPSA) — MPSA  an  administrator 
to  easily  check  the  security  stance  and  patch  state  of  a  Windows  NT  4.0 
Workstation  or  a  Windows  2000  Professional  computer.  Using  this  web 
application,  the  administrator  can  scan  a  computer  and  receive  a  detailed 
report  on  that  computer’s  security  settings,  along  with  recommendations  for 
updates  and  improvements.  (See  Appendix  F  for  more  information  about 
MPSA.) 

•  Microsoft  Network  Security  Hotfix  Checker  (HfNetChk) — This  a 
command  line  tool  written  by  Microsoft  to  assess  the  patch  status  for 
Windows  NT  4.0  and  Windows  2000  operating  systems,  as  well  as  the 
status  of  hotfixes  for  IIS  4.0  and  5.0,  SQL  Server  7.0  and  2000,  and 
Internet  Explorer  5.01  and  later.  (See  Appendix  G  for  information  and 
instructions  on  its  use). 

•  Microsoft  Security  Toolkit,  Strategic  Technology  Protection  Program 
(STPP) — Microsoft  has  recently  started  this  program.  This  along  with  the 
Microsoft  Security  Toolkit,  is  a  two-phased  program.  The  first  phase  of  the 
program  is  to  get  secure  and  the  second  phase  is  to  stay  secure.  More 
information  on  this  new  program  and  the  associated  toolkit  can  be  found  at 
http://microsoft.com/securitv. 

•  Windows  Critical  Update  Notification — This  tool  checks  for  an  Internet 
connection  every  5  minutes  and,  when  a  connection  is  found,  checks  for 
any  updates.  The  tool  connects  to  the  Windows  Update  site,  and  then 
notifies  the  user  of  any  critical  updates  or  patches  that  are  available.  The 
frequency  of  checking  for  an  Internet  connection  slows  down  to  once  per 
hour  after  the  first  hour  of  unsuccessful  attempts  and  stops  for  1  day  after  a 
successful  update.  This  tool  and  additional  information  about  it  can  be 
found  at  http://support.microsoft.eom/support/kb/articles/Q224/4/20.ASP. 

•  Microsoft  Security  Notification  Service — This  free  service  that  provides 
e-mail  notification  from  Microsoft  about  the  security  of  Microsoft  products. 
Information  on  this  service  and  how  to  subscribe  can  be  found  at 
http://www.microsoft.com/technet/securitv/bulletin/notifv.asp. 

All  of  these  Microsoft  services  or  applications  provide  means  of  checking  and 
installing  patches.  Many  forms  of  patches  and  methods  of  applying  patches  exist. 
Critical  patches  can  come  in  the  form  of  critical  updates  and  hotfixes  while 
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noncritical  updates  can  come  in  the  form  of  service  packs  and  product  updates. 
Noncritical  updates  usually  are  feature  enhancement  packages. 

Although  service  packs  can  be  classified  as  noncritical  updates,  they  do  contain 
previously  released  critical  updates  within  them.  All  Hotfixes  and  Critical  Updates 
that  are  released  prior  to  a  service  pack  (including  all  patches  and  updates  from 
previous  service  packs)  are  usually  bundled  into  the  next  service  pack  when  it  is 
released. 

When  Microsoft  Hotfixes  are  applied,  a  reboot  is  usually  required  after  the 
installation.  When  multiple  hotfixes  must  be  downloaded  and  installed,  this  can 
become  a  time-consuming  task.  To  correct  this  problem,  Microsoft  has  released 
another  tool,  QChain,  that  enables  hotfixes  to  be  bundled  into  one  package  and 
installed  at  one  time.  QChain  and  additional  usage  information  can  be  found  at 
http://support.microsoft.eom/support/kb/articles/Q296/8/61  .aso  This  product  can 
also  allows  administrators  to  create  a  customized  patch  installer  for  multiple 
systems  that  all  require  the  same  patches. 

Automated  Patch  Distribution  and  Application  Tools 

While  applying  patches  to  10-15  servers  may  seem  a  daunting  task,  it  is  nothing 
compared  to  rolling  out  a  patch  to  hundreds  or  thousands  of  desktop  systems.  This 
task  can  be  made  easier  through  applications  that  automatically  distribute  updates 
to  end-user  computers.  Some  of  these  patch  automation  tools  are  included  with 
network  operating  system  software  while  third-party  vendors  distribute  others. 

The  capabilities  of  these  systems  vary  greatly.  Some  of  these  applications  focus  on 
the  distribution  of  patches.  They  rely  on  the  system  or  network  administrator  to 
identify  a  necessary  patch  and  setup  the  patch  distribution  tool  to  deliver  and  install 
the  patch.  Other  will  actively  search  for  necessary  patches  and  suggest  these  to 
the  system  administrator  and,  at  his  or  her  command,  install  the  patches  on  the 
appropriate  hosts. 

These  patch  distribution  applications  also  vary  greatly  in  their  support  of  different 
operating  systems  and  applications.  Those  those  that  are  bundled  with  an 
operating  system  tend  to  support  the  fewest  operating  systems  and  applications. 
Those  from  third-party  vendors  are  generally  compatible  with  the  widest  range  of 
systems. 

Patching  After  a  Security  Compromise 

Patching  after  a  security  compromise  is  significantly  more  complicated  than  merely 
applying  the  appropriate  patch(es).  While  applying  a  patch  after  a  security 
compromise  will  generally  correct  the  vulnerability  that  was  exploited,  it  will  not 
eliminate  backdoors6  or  most  other  changes  that  might  have  been  introduced  by  the 
intruder.  For  example,  the  Code  Red  II  worm  placed  backdoors  on  compromised 
systems.  Hackers,  and  even  the  Nimda  worm  that  came  after  Code  Red  II,  then 
exploited  these  backdoors.  Administrators  who  patched  their  systems  after  a 
compromise  by  Code  Red  II  fixed  the  original  vulnerability  but  not  the  backdoor. 

Systems  that  are  known  or  suspected  to  have  been  compromised  must  be  patched 
more  carefully  than  uncompromised  systems.  Generally  speaking,  if  a  system  has 


6  A  backdoor  is  a  secret  avenue  of  access  placed  on  a  compromised  computer  system  by  a  hacker  that 
allows  him  or  her  future  access  to  the  system. 
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been,  or  is  suspected  of  being  compromised  it  must  be  reformatted  and  reinstalled 
or  restored  from  a  known  good  backup.  If  that  is  not  possible,  significant  expertise 
will  be  required  managing  the  possible  dangers  inherent  in  compromised  systems. 

Some  to  consider  when  in  deciding  whether  to  reinstall  a  compromised  system  are 
as  follows: 

•  Level  of  access  to  the  intruders  attained  (root,  user,  guest,  system,  etc.) 

•  Purpose  of  compromising  the  system  (e.g.,  web  page  defacement,  illegal 
software  repository,  platform  for  other  attacks,  etc.) 

•  Method  of  system  compromise 

•  Actions  of  hacker  during  and  after  compromise  (e.g.,  erased  log  files, 
intrusion  detection  reports,  etc.) 

•  Duration  of  compromise 

•  Extent  of  compromise  on  network  (i.e.,  the  number  of  machines 
compromised  on  network) 

•  Results  of  consultation  with  management  and  legal  counsel. 

The  lower  the  level  of  access  and  the  more  the  administrator  knows  about  the 
hackers  actions  the  less  risk  there  is  in  patching  the  vulnerability  as  opposed  to 
reinstalling  the  whole  operating  system. 

System  administrators  also  need  to  keep  in  mind  if  they  wish  to  pursue  any  sort  of 
criminal  prosecution  for  the  compromise  they  cannot  in  any  way  alter  the 
compromised  host  or  else  it  may  not  be  used  for  evidence.  There  are  very  specific 
guidelines  on  the  handling  of  a  host  after  a  compromise  if  it  is  to  be  used  in 
evidence  for  criminal  prosecution  of  civil  litigation. 

To  recover  from  a  compromise  the  following  steps  should  be  taken: 

•  Immediately  disconnect  compromised  system(s)  from  network 

•  Consult  organizational  security  policy 

•  Consult  with  management,  legal  counsel,  management  and  law 
enforcement  as  appropriate 

•  Analyze  intrusion  including: 

o  Modifications  made  to  system  software  and  configuration 
o  Modifications  made  to  data 
o  Tools  or  data  left  behind  by  intruder 
o  Review  system,  intrusion  detection  and  firewall  log  files. 


30 


Restore  system 
o  Two  options: 

■  Install  clean  version  of  operating  system  or 

■  Restore  from  backups  (much  more  risky) 
o  Disable  unnecessary  services 

o  Apply  all  security  patches 
o  Change  all  passwords 

o  Reconfigure  network  security  elements  (firewall,  router,  intrusion 
detection  system,  etc.)  to  provide  additional  protection. 

Update  security  policy 


Document  lessons  learned. 


Appendix  A:  Patching  Resources 


Cisco 


Topic 

Website 

Cisco  Security  Advisories 

httD://www.cisco.com/warD/oublic/707/advisorv.html 

Cisco  Technical  Assistance 
Center  (TAC) 

htto://www.cisco.com/Dublic/suooort/tac/home.shtml 

Cisco  IOS  Reference  Guide 

htto://www.cisco.com/warD/oublic/620/1  .html 

Cisco  Security  Tips 

htto://www.cisco.com/warD/Dublic/707/ 

Improving  Security  on  Cisco 
Routers 

htto://www.cisco.com/warD/oublic/707/21  .html 

Cisco  Product  Security 

Incident  Response 

httD://www.cisco.com/warD/oublic/707/sec  incident  resoonse.shtml 

Troubleshooting  Security 

htto://www.cisco.com/warD/Dublic/1 1 2/chaoter24.htm 

Subscription  to  the  Cisco 

TAC  Newsletter 

httD://www.cisco.com/Dublic/news  trainina/itsnews/subscribe.shtml 

Cisco  Tool  Index 

httD://www.cisco.com/oublic/suDDort/tac/t  index.shtml 
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Microsoft 


Topic 

Website 

Microsoft 

htto  ://www.  m  icrosoft.com 

Strategic  Technology 
Protection  Program 

httD://www. microsoft.com/securitv 

Windows  Critical  Update 
Notification 

httD://suDDort. microsoft.com/suooort/kb/articles/Q2 

24/4/20  .ASP 

Microsoft  Security 
Notification  Service 

httD://www. microsoft.com/technet/securitv/bulletin/notifv.asD 

QChain 

httD://suDDort.microsoft.com/suDDort/kb/articles/Q296/8/61  .as 

e 

Qfecheck 

httD://suDDort.microsoft.com/suDDort/kb/articles/Q282/7/84.A 

SP 

Windows  Update 

httD://windowsuDdate. microsoft.com 

Corporate  Windows 

Update 

httD://coroorate.wi  ndowsuDdate.microsoft.com 

Office  Update 

htto://office. microsoft.com/downloads 

Microsoft  Downloads 

htto://www.  microsoft.com/downloads 

Microsoft  Product  Support 
Services 

httD://suDDort.microsoft.com/directorv 

Microsoft  Personal 

Security  Advisor 

htto  ://www.  m  icrosoft  .com/tech  net/mosa/start.asD 

HFNetChk 

httD://suDDort.microsoft.com/suDDort/kb/articles/a303/2/15.as 

D?id=30321 5&sd=tech 

Maximized  Software 

Hotfix  Reporter 

htto://www.  maximized.com/freeware/hotfixreoorter/ 
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Linux/Unix  Distribution  Websites 


Operating  System 

Website 

Armed  Linux 

httD  ://www .  arm  ed .  net/ 

Astaro  Security  Linux 

httD://www.astaro.com/ 

Beehive  Linux 

httD://www.beehive.nu/ 

BestLinux 

htto  ://www.  bestl  i  n  ux .  net/ 

BlueCat  Linux 

htto  ://www.  Ivnuxworks  .com/ 

Caldera  OpenLinux 

httD://www.calderasvstems.com/ 

ChainSaw  Linux 

httD://www.chainsawlinux.com/ 

Conectiva  Linux 

htto  ://en  .conectiva.com/ 

Corel  Linux 

httD://linux.corel.com/ 

Coyote  Linux 

htto  ://www.  vortech .  net/covote/ 

CRUX 

htto://crux.nu/ 

Debian  GNU/Linux 

httD://www.debian.ora/ 

Demo  Linux 

httD://demolinux.ora/en/aui/aui.html 

Dettu[Xx]  Linux 

httD://dettus.dvndns.ora/dettuxx 

Devil-Linux 

htto  ://www.devil-linux. ora/ 

DLX  Linux 

httD://www.wu- 

wien.ac.at/usr/h93/h9301726/dlx.html 

DragonLinux 

httD://www.draaonlinux.net/ 

easyLinux 

httD://www.eit.de/ 

Elfstone  Linux 

httD://www.elflinux.com/linux.html 

EnGarde  Secure  Linux 

htto  ://www.  1  i  n  ux  .ora/d  i  st/ 

FlightLinux 

httD://fliahtlinux.asfc.nasa.aov/ 

FreeBSD 

htto  ://www  .f  reebsd .  ora/ 

Freesco 

htto  ://www.freesco. ora/ 

GCL  -  Grey  Cat  Linux 

htto  ://www  .a  revcat  1  i  n  ux .  m  vweb .  n  1/ 

Gentoo  Linux 

htto  ://www.aentoo.  ora/ 

Gentus  Linux 

httD://www.aentus.com/ 

hal91  Floppy  Linux 

httD://isDiro.triDod.com/linux/hal91  .htm 

Hard  Hat  Linux 

httD  ://www.  mvista.com/ 

Icepack  Linux 

httD  ://www. iceoack-linux.com/ 

Immunix  OS 

httD://www.wirex.com/ 

JB  Linux 

httD  ://www. iblinux.com/ 

Jurix  Linux 

htto://www.iurix.ora/ 
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Operating  System 

Website 

KRUD 

httD://www.tummv.com/krud/ 

KYZO 

htto://www.kvzo.com/ 

L13Plus 

htto://l1 3olus.deuroconsult.ro/ 

Linux  Antartica 

htto://www. Iinuxantarctica.com/ 

Linux  by  LibraNet 

htto://www.libranet.com/ 

Linux  Embedded 

htto  ://l  inux  -embedded  .com/ 

Linux  Mandrake 

htto://www.linux  -mandrake.com/ 

Linux  Pro 

htto://www.was.com/ 

LinuxOne 

htto  ://www.linuxone. net/ 

LinuxPPC 

htto  ://www.  1  i  n  uxddc  .  ora/ 

LinuxWare 

htto://www.trans  -am.com/indexi  .htm 

LoopLinux 

htto://www.tux.ora/Dub/Deoole/kent- 

robotti/i  ndex.html 

LuteLinux 

htto://www.lutelinux.com/ 

MaxOS 

htto  ://www.  maxos  .com/ 

Midori  Linux 

htto  ://m  idori.transmeta.com/ 

MkLinux 

htto://www.mklinux.ora/ 

Monkey  Linux 

htto  ://www. sosselib.hiedu.cz/monkev/ 

muLinux 

htto  ://sunsite. auc.dk/mulinux/ 

OpenBSD 

htto://www.ooenbsd.ora/ 

Peanut  Linux 

htto  ://m  etalab.unc.edu/oeanut/ 

Phat  Linux 

htto://www.ohatlinux.com/ 

Pocket  Linux 

htto  ://oocket -linux.coven.vmh.net/about.html.en 

Progeny  Debian 

htto  ://www. oroaenv.com/ 

Pygmy  Linux 

htto://ovamv.oenauin.cz/ 

RedHat  Linux 

htto  ://www. redhat.com/ 

Redmond  Linux 

htto://www.redmondlinux.ora/ 

Rock  Linux 

htto :  //www .  rockl  i  n  ux .  ora/ 

RT-Linux 

htto  ://www .  rtl  i  n  ux  .ora/rtl  i  n  ux/ 

Slackware  Linux 

htto  ://www.  slackware.com/ 

Spinix 

htto://www.ibiblio.ora/soinix 

Stampede  Linux 

htto://www.stamoede.ora/ 

SuSE  Linux 

htto  ://www. suse.com/ 

ThinLinux 

htto  ://www  .thinlinux.  ora/ 

TINY  Linux 

htto  ://tinv.seul. ora/ 
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Operating  System 

Website 

tomsrtbt 

httD://www.toms.net/rb/ 

Trustix  Secure  Linux 

httD://www.trustix.net/ 

TurboLinux 

httD://www.turbolinux.com/ 

White  Dwarf  Linux 

htto://www. emiembedded.com/linux/dimmDC.html 

WholeLinux 

httD://www.wholelinux.com/ 

WinLinux  2000 

htto://www.winlinux.net/ 

Yellow  Dog  Linux 

httD://www.vellowdoalinux.com/ 

Yggdrasil  Linux 

httD://www  .vaadrasil.com/ 

ZipHam 

httD://ziDham.free.fr/ 
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Popular  Linux/Unix  Distribution  Download/Update/Security  Websites 


Operating  System 

Website 

Debian 

Debian  Security  Information 

httD://www.debian.ora/securitv/ 

Debian  Distribution 

httD://www.debian.ora/distrib/ 

Debian  Support 

httD://www.debian.ora/suDoort 

Debian  Mailing  Lists 

httD://www.debian.ora/MailinaLists/ 

Mandrake 

Mandrake  Security  Information 

httD://www. Iinux-mandrake.com/en/securitv/ 

Mandrake  Distribution 

httD://www.linux -mandrake.com/en/ftD.DhD3 

Mandrake  Support 

httD://www.linux -mandrake.com/en/fdoc.DhD3 

Mandrake  Mailing  Lists 

htto://www. linux-mandrake.com/en/flists.DhD3 

RedHat 

RedHat  Security  Information 

htto://www. redhat.com/suDDort/alerts/ 

RedHat  Distribution 

httD://www. redhat.com/aDDs/download/ 

RedHat  Support 

htto://www. redhat.com/aDDs/suDDort/ 

RedHat  Mailing  Lists 

htto://www. redhat.com/mailina-lists/ 

SuSE 

SuSE  Security  Information 

htto://www. suse.com/us/suDDort/securitv/index. 

html 

SuSE  Distribution 

httD://www.suse.com/us/suDDort/download/suse 

linux/index. html 

SuSE  Updates 

httD://www.suse.com/us/suDDort/download/uDda 

tes/i  ndex.html 

SuSE  Support 

httD://sdb.suse.de/en/sdb/html/ 

SuSE  Mailing  Lists 

httD://www.suse.com/de/suDDort/mailinalists/ind 

ex. html 

Slackware 

Slackware  Security  Information 

Slackware  Distribution 

httD://www.slackware.com/aetslack/ 

Slackware  Support 

htto  ://www .  slackware.com/su  DDort/ 

Slackware  Mailing  Lists 

httD://www.slackware.com/lists/ 

Caldera 

Caldera  OpenLinux  Security 
Information 

httD://www.caldera.com/suDDort/securitv/ 

Caldera  OpenLinux  Distribution 

httD://www.caldera.com/download/ 
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Operating  System 

Website 

Caldera  OpenLinux  Support 

httD://www.caldera.com/suoDort/ 

FreeBSD 

FreeBSD  Security  Information 

htto  ://www.f  reebsd  .ora/secu  ritv/index.  htm  1 

FreeBSD  Distribution 

httD://www.freebsd.ora/doc/en  US.IS08859- 

1 /books/handbook/mirrors. html 

FreeBSD  Support 

httD://www.freebsd.ora/suDDort.html 

FreeBSD  Mailing  Lists 

httD://www.freebsd.ora/suDDort.html#mailina-list 

OpenBSD 

OpenBSD  Security  Information 

httD://www.ooenbsd. ora/secu  ritv.html 

OpenBSD  Distribution 

htto  ://www.ooenbsd.ora/ftD. html 

OpenBSD  Patches 

htto://www.oDenbsd.ora/errata.html 

OpenBSD  Support 

htto  ://www.ooenbsd.ora/docum. html 

OpenBSD  Mailing  Lists 

htto  ://www.ooenbsd. ora/mail. html 

TrustedBSD 

Trusted  BSD  Security 

Information 

TrustedBSD  Distribution 

httD://www.trustedbsd.ora/downloads/ 

TrustedBSD  Support 

httD://www.trustedbsd. ora/documentation/ 

TrustedBSD  Mailing  Lists 

httD://www.trustedbsd.ora/mailinalists/ 

Solaris  Security  Information 

Solaris  Security  Information 

httD://www.sun.com/securitv/ 

Solaris  Distribution 

htto  ://www.sun.com/software/solaris/aet. html 

Solaris  Live  Upgrade 

httD://www. sun.com/solaris/liveuoarade/ 

Solaris  Support 

htto://www.sun.com/software/solaris/services.ht 

mi 

Solaris  Forums,  Patch 
Documentation,  and  Patch 
Downloads 

htto  ://suDDortforum.  sun.com/freesolaris/ 
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Virus  Software  Download/Update/Security  Centers 


Topic 

Website 

McAfee  Anti-Virus 

McAfee  Anti-Virus 

httD  ://www.  mcafee.com/anti  -vi  rus/ 

McAfee  Anti-Virus  Updates 

httD://download. mcafee.com/uDdates/uDdates.asD 

McAfee  Anti-Virus  Upgrades 
and  Patches 

httD ://down load. mcafee.com/uDdates/uDarade  oatches.asD 

McAfee  Evaluation  Download 

httD  ://download .  me  afee.com/eval/ 

McAfee  Mailing  List 

httD  ://disDatch. mcafee.com/ 

McAfee  Hoax  Page 

httD  ://vil.  mcafee.com/hoax.asD? 

Symantec  Norton  Anti-Virus 

Symantec  Norton  Anti-Virus 

httD://www.sarc.com/avcenter/ 

Norton  Anti-Virus  Definitions 

httD://www.svmantec.com/avcenter/defs.download.html 

Removal  Tools 

httD  ://www. sarc.com/avcenter/tools. Iist.html 

Updates/Downloads 

httD://www.svmantec.com/techsuDD/files.html 

Symantec  Product  Security 
Advisories 

httD://www.sarc.com/avcenter/securitv/SvmantecAdvisories.ht 

ml 

Symantec  Online  Virus  and 
Security  Check 

htto://www. svmantec.com/securitvcheck/ 

Mailing  List/  News  Bulletin 

httD  ://www. svmantec.com/techsuDD/bulletin/index.html 

Antivirus  Hoax  Page 

httD://www.sarc.com/avcenter/hoax.html 

Panda  Anti  -Virus 

Panda  Anti-virus  Home 

httD://www.Dandasecuritv.com/Dlatinuminfo.htm 

Panda  Anti-virus  Global 

httD://www.Dandasecuritv.com/aviinfo.htm 

Sophos  Anti-Virus 

Sophos  Anti-Virus 

httD  ://www. soDhos.com/Droducts/antivirus/ 

Sophos  Evaluation 

httD://www.soDhos.com/downloads/Droducts/ 

Sophos  Virus  Definition 

Updates 

httD  ://www. soDhos.com/downloads/ide/ 

Sophos  Mailing  List 

httD://www.soDhos.com/virusinfo/notifications 

Sophos  Supports 

htto://www. soDhos.com/suDDort/ 

Central  Command 

Central  Command 

httD://www.centralcommand.com/Droducts.html 

Central  Command  Support 

httD://suDDort.centralcommand.com/cai- 

bin/command.cfa/DhD/enduser/home.DhD 

Central  Command  Updates 

httD://www.centralcommand.com/uDdate.html 
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Topic 

Website 

F-Secure  Anti-Virus 

F-Secure  Anti-Virus 

htto://www.fsec  ure.com/oroducts/anti-virus/ 

F-Secure  Virus  Info 

htto://www.fsecure.com/virus-info/ 

Miscellaneous  Anti-Virus  Resources 


Virus  Bulletins 

htto://www.virusbtn.com/ 

AntiVirus  Product  Developers 

List 

htto  ://www.  virusbtn  .com/A’ VLi  nks/ 

Virus  Bulletins  Hoax  Page 

htto  //www.  vi  rusbtn  .com/Hoax/ 
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Appendix  B:  Using  the  ICAT  Website 


The  ICAT  Metabase  is  a  searchable  index  of  computer  vulnerabilities.  ICAT  links 
users  to  a  variety  of  publicly  available  vulnerability  databases  and  patch  sites,  thus 
enabling  administrators  to  identify  and  correct  vulnerabilities  existing  on  their 
systems.  ICAT  is  not  itself  a  vulnerability  database,  but  is  instead  a  searchable 
index  leading  one  to  vulnerability  resources  and  patch  information.  ICAT  allows  one 
to  search  at  a  fine  granularity,  a  feature  unavailable  with  most  dedicated 
vulnerability  databases,  by  characterizing  each  vulnerability  by  over  40  attributes 
(including  software  name,  version  number  impact,  exploitable  range,  etc.).  ICAT 
indexes  the  information  available  in  CERT  advisories,  ISS  X-Force,  Security  Focus, 
NT  Bugtraq,  Bugtraq,  and  a  variety  of  vendor  security  and  patch  bulletins.  ICAT 
does  not  compete  with  publicly  available  vulnerability  databases  but  instead  is  a 
search  engine  that  drives  traffic  to  them.  ICAT  is  maintained  by  NIST. 

ICAT  uses,  and  is  completely  based  on,  the  Common  Vulnerabilities  and  Exposures 
(CVE)  naming  standard,  an  industry  standard  naming  scheme  for  computer 
vulnerabilities  and  exposures  that  ICAT  uses  to  index  its  vulnerability  information. 
Information  on  the  CVE  can  be  found  at  http://www.cve.mitre.org/. 

Accessing  the  ICAT  Metabase: 

ICAT  is  accessible  to  all  users  with  a  web  browser  and  access  to  the  Internet.  It  is 
located  at  http://icat.nist.gov  (see  Figure  B-1). 


Figure  B-1  — Accessing  ICAT  Metabase 

Navigating  the  ICAT  Metabase  Website: 

The  ICAT  Metabase  homepage  provides  a  variety  of  information  and  links  that  will 
assist  the  user  in  utilizing  the  ICAT  Metabase. 
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The  navigation  bar  at  the  top  of  the  screen  allows  users  to  use  and  navigate  the 
ICAT  Metabase  website  (see  Figure  B-2). 


ICAT 


METABASE 


NIST 


Your  CVt  Vulnniohilrty  Stimrh  tnginn 
SFARCH  DOWNIOAD  NOTIFICATION  CONTACT  INFO  TOPTFNIIST  STATISTICS 


Figure  B-2  —  ICAT  Metabase  Navigation  Bar 

•  Search — Returns  the  user  to  the  homepage/search  page.  From  here  the 
user  can  conduct  searches  of  the  ICAT  Metabase  (see  section  on 
searching  below  for  more  information). 

•  Down  I  oa  d — Opens  the  1C  A  T  Download  and  Product  Integration  Section, 
which  allows  users  to  download  “standalone”  versions  of  the  ICAT 
database.  This  is  useful  for  users  who  wish  to  have  access  to  the 
database  when  not  connect  to  the  Internet  or  for  developers  who  wish  to 
integrate  ICAT  information  into  their  application. 

•  Notification — Opens  the  ICAT  Based  Vulnerability  Notification  Systems 
page.  This  page  provides  information  on  automated  notification 
applications  that  employ  the  ICAT  Metabase.  These  applications  will  notify 
users  of  new  entries  to  the  ICAT  Metabase  that  are  related  to  the  software 
employed  by  the  user.  Links  on  this  page  allow  users  to  download  these 
applications  from  their  creators’  websites. 

•  Contact — Opens  the  ICAT  Contact  Information  page.  The  page  contains 
contact  information  for  the  ICAT  staff.  Users  are  encouraged  to  provide 
information  on  how  they  use  the  ICAT,  to  download  ICAT  advertising 
banners  and  provide  a  links  to  the  ICAT  Metabase  from  their  website. 

•  Info — Opens  a  new  browser  window  and  opens  the  ICAT  Metabase 
Documentation  page.  This  page  provides  answers  to  frequently  asked 
questions  (FAQ)  about  the  ICAT  metabase. 

•  Top  Ten  List — Opens  the  ICAT  Top  Ten  List  vulnerabilities  page.  This 
page  contains  a  table  that  contains  the  top  ten  most  popular  vulnerabilities 
as  defined  by  the  number  or  requests  made  for  a  particular  vulnerability 
through  the  ICAT  metabase.  To  maintain  timeliness  of  this  information, 
only  vulnerabilities  published  within  the  last  year  are  included  in  the  list. 

•  Statistics— Opens  the  ICAT  Vulnerability  Statistics  page.  This  page 
contains  statistics  on  the  characteristics  of  the  vulnerabilities  contained  in 
the  ICAT  metabase. 
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Welcome  to  /CAT! 


ICAT  Metabase  Sidebar 


ICAT  cofitfens 

7916  vulruif  abilities 

Last  updated 
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granularity  and  fenks 
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and  patch  eifovmaflion 
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The  ICAT  team 
appreciates  the 
contributions  and 
support  of  the  following 
organizations  CERIAS 
FeilCIRC.  ISS 
X  T orce.  WAP,  SANS 
Institute,  and  Security 
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The  ICAT  Mel  abase  is  a 
product  oftha  Computer 
Security  Ovision  at  the 


The  sidebar  can  be  found  on  the  ICAT  homepage  and  most 
other  pages  on  the  site  (see  Figure  B-3). 

•  The  top  of  the  sidebar  provides  the  number  of 
vulnerabilities  contained  with  the  metabase,  the  last 
update  and  a  brief  overview  of  the  ICAT. 

•  The  sidebar  also  allows  a  user  to  register  for  the 
ICAT  mailing  list.  Important  announcements  about 
ICAT  are  sent  out  to  subscribers  of  this  list.  It  has 
an  extremely  low  volume  (only  a  few  e-mails  per 
year). 

•  The  lower  half  of  the  sidebar  provides  links  to  the 
websites  of  organizations  that  support  the  ICAT. 
These  sites  may  be  of  use  or  interest  to  users  of 
the  ICAT.  Some  of  these  links  are  to  sites  external 
to  NIST.  Note:  When  attempting  to  access  an 
external  site,  there  is  an  exit  notification  from  the 
NIST  website  prior  to  accessing  the  external  site. 

To  speed  loading  of  the  external  site  click  on  the 
hyperlink  provided  after  reading  the  disclaimer. 

•  The  side  bar  also  provides  links  to  press  articles 
concerning  ICAT. 


Figure  B-3  — 

ICAT  Sidebar 

that  year.  When  a 


Common  Vulnerabilities  and  Exposures  (CVE) 

The  CVE  is  the  common  vulnerabilities  and  exposures  list.  It  is 
an  industry  standard  naming  scheme  for  computer 
vulnerabilities  and  exposures  that  the  ICAT  employs  to  index 
its  vulnerability  information.  Vulnerabilities  will  be  named 
either  CVE-xxxx-yyyy  or  CAN-xxxx.yyyy.  The  CVE  prefix  is 
attached  to  vulnerabilities  that  have  been  reviewed  by  the 
CVE  standard  advisory  committee.  The  CAN  prefix  is  for 
candidates  under  review  by  the  advisory  committee.  The 
candidates  have  been  filtered  by  MITRE  to  ensure  some 
degree  of  accuracy,  but  there  is  no  guarantee  that  a  CAN 
entry  is  a  unique  or  real  vulnerability.  The  xxxx  part  of  each 
entry  represents  the  year  in  which  the  vulnerability  entered 
the  CVE  process.  The  yyyy  part  of  each  entry  is  a  unique 
number  assigned  to  entries  submitted  to  the  CVE  committee 
CAN  entry  is  approved  by  the  CVE  committee,  the  prefix  is 


changed  from  CAN  to  CVE  while  leaving  the  number  the  same. 


Searching  the  ICAT  Metabase 


The  ICAT  Metabase  has  a  variety  of  powerful  search  features.  The  search  engine 
is  available  from  the  ICAT  Metabase  homepage  (see  Figure  B-4).  It  is  possible  to 
search  by  the  date  when  the  vulnerability  was  published,  vendor  name,  product 
name,  version  (available  only  when  a  product  is  selected),  keyword  search  and/or 
severity  level.  ICAT  also  provides  filters  allowing  users  to  limit  their  search  results  to 
particular  sources,  exploit  range,  vulnerability  consequence,  vulnerability  type, 
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operating  system  type,  expose  component  type,  entry  type  and  those  vulnerabilities 
published  after  a  particular  date. 


Figure  B-4  —  ICAT  Metabase  Navigation  Bar 

Defining  Search  Parameters 

Before  conducting  a  search,  it  will  be  necessary  to  define  the  search  parameters.  A 
number  of  methods  are  available  in  the  ICAT  Metabase.  Multiple  parameters  can 
be  set  in  order  to  narrow  the  search.  The  “Reset  values”  button  resets  all  the 
search  parameters  and  filters  back  to  the  default  (see  Figures  B-4  and  B-5).  With 
limited  exception  noted  below  users  can  use  as  few  or  as  many  of  the  search 
parameters  and  filters  as  required. 

Date  of  Publication — The  buttons  along  the  top  of  the  search  parameters  section 
(see  Figure  B-5)  allow  users  to  search  for  vulnerabilities  by  date  of  publication.  The 
results  will  be  ordered  from  most  recent  to  oldest  within  the  parameters  set  by  the 
user. 
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Search- >  All  entries 


1  Year 


6  Months 


3  Months 


Reset  values 


Figure  B-5  —  Date  of  Publication  Search 

Vendor — The  letters  on  the  vendor  line  allow  users  to  search  for  vulnerabilities  by 
the  name  of  the  vendor.  Selecting  a  letter  on  the  vendor  line  will  open  a  drop  down 
menu  with  all  vendor  names  starting  with  that  letter  (see  Figure  B-6).  A  user  can 
select  the  vendor  of  their  choice  by  scrolling  down  the  list  and  clicking  on  the  vendor 
of  their  choice.  The  user  can  start  their  search  by  clicking  on  the  appropriate  search 
button  (see  Figure  B-5)  or  narrow  their  search  further  by  selecting  a  product  from 
the  vendor’ s  product  list  (see  below).  Note:  as  with  all  drop  down  boxes  on  the 
ICAT  search  page  the  user  may  select  only  one  vendor  at  a  time. 


Vendor 

Any . 

▼ 

Product 

Any . 

▲ 

Version 

LOpht 

Keyword  search 

Larry  Wall 

Lars  Ellingsen 

(try  a  CVE  or  CAN  name) 

LBL 

Severity 

LCDProc 

LeafDigital 

General  Filters: 

Lee  McLoughlin 

Leif  M.  Wright 

Common  Sources 

Related  exploit  range 

Lenzo 

Lexmark 

LICQ 

Vulnerability  consequence 

LIDS 

Lightwave 

Vulnerability  type 

Lilikoi 

OS  Type 

Lincoln  D.  Stein 

Linksys 

Exposed  component  type 

Linux 

Entry  type 

Listmanager 

Livingston 

▼ 

Figure  B-5  —  Vendor  Search 

Product — If  a  vendor  has  not  already  been  selected,  the  user  can  click  on  the  letter 
that  begins  the  name  of  the  product  that  they  are  interested  in  searching.  If  they 
have  already  selected  a  vendor  (see  above)  then  there  will  be  a  drop  down  box  with 
that  vendors  products  listed  (see  Figure  B-6).  The  user  can  select  a  product  by 
scrolling  down  the  list  and  clicking  on  the  appropriate  choice.  Note:  as  with  all  drop 
down  boxes  on  the  ICAT  search  page  the  user  may  select  only  one  product  at  a 
time. 
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Vendor 

Product 

Version 

Keyword  search 

(try  a  CVE  or  CAN  name) 

Severity 


Lucent 

1  Any . 

d 

Acsend  MAX  Router 

Ascend  Pipeline  Router 

Ascend  Routers 

Ascend  TNT  Router 

ORiNOCO 

RADIUS 

Figure  B-6  —  Product  Search 

(Product)  Version — This  option  is  only  available  if  the  user  has  selected  a  product. 
This  search  allows  a  user  to  select  a  particular  version  of  a  product  (see  Figure  B- 
7).  Given  the  large  number  of  versions  for  certain  products,  it  is  possible  that  using 
this  option  will  cause  the  metabase  to  not  return  all  possible  vulnerabilities.  Note:  as 
with  all  drop  down  boxes  on  the  ICAT  search  page  the  user  may  select  only  one 
version  at  a  time. 


Vendor 

Product 

Version 

Keyword  search 

(try  a  CVE  or  CAN  name) 

Severity 

General  Filters: 
Common  Sources 

Related  exploit  range 


Lucent 

Acsend  MAX  Router 

▼ 

|Any . 

d 

Any . 

NOTE,  ICAT  may  not  contain  all  vulnerable  version  numbers 
Using  this  option  may  cause  one  to  overlook  vulnerabilities 


1 

2 

3 

4 

5 


Figure  B-7  —  Product  Version  Search 

Keyword — Allows  the  user  to  narrow  their  search  using  keywords  (see  Figure  B-8). 


Keyword  search 


enter  keywords  here 


Figure  B-8  —  Keyword  Search 

Severity — Allows  the  user  to  narrow  their  search  by  severity  level  (see  Figure  B-9). 
Note:  as  with  all  drop  down  boxes  on  the  ICAT  search  page  the  user  may  select 
only  one  severity  level  choice  at  a  time. 
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Figure  B-8  —  Keyword  Search 


Defining  Search  Filters 

Optionally,  the  user  can  select  filters  to  further  narrow  their  search.  The  “Reset 
values”  button  resets  all  the  search  parameters  and  filters  back  to  the  default  (see 
Figures  B-4  and  B-5).  With  limited  exceptions  noted  below  users  can  use  as  few  or 
as  many  of  the  search  parameters  and  filters  as  required. 

Common  Sources— This  filter  allows  a  user  to  select  a  specific  source  or 
vulnerabilities  (see  Figure  B-9).  Note:  as  with  all  drop  down  boxes  on  the  ICAT 
search  page  the  user  may  select  only  one  source  at  a  time. 


Common  Sources 


|  Any . 

. zl 

Any . 

CERT 

ISS  X-Force 

Microsoft 

Neohapsis 

Security  Focus 

Figure  B-9  —  Common  Source  Search  Filter 

Related  Exploit  Range — This  filter  allows  a  user  to  limit  their  search  to  local 
vulnerabilities  (those  that  require  local  access  to  exploit)  or  remote  vulnerabilities 
(those  that  can  be  exploited  without  local  access  to  a  host).  This  filter  option  is 
shown  in  Figure  B-10.  Note:  as  with  all  drop  down  boxes  on  the  ICAT  search  page 
the  user  may  select  only  one  option  at  a  time 


Related  exploit  range 


Any . 

▼ 

Any . 

Remote 

Local 

Figure  B-10  —  Exploit  Range  Search  Filter 


Vulnerability  Consequence — Filters  the  results  based  on  the  consequence  of  the 
vulnerability  (e.g.,  root  level  access,  availability,  etc.).  Figure  B-11  shows  the 
options  for  this  filter.  Note:  as  with  all  drop  down  boxes  on  the  ICAT  search  page 
the  user  may  select  only  one  consequence  at  a  time. 
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Vulnerability  consequence 


I  Any .  jJ 


Availability 

Confidentiality 

Integrity 

Security  protection 
(root  level  access) 
(user  level  access) 
(other  access) 


Figure  B-11  — Vulnerability  Consequence  Search  Filter 


Vulnerability  Type — Filters  the  results  based  on  the  root  cause  of  the  vulnerability 
(e.g.,  root  level  access,  availability,  etc.).  Figure  B-12  shows  the  options  for  this 
filter.  Note:  as  with  all  drop  down  boxes  on  the  ICAT  search  page  the  user  may 
select  only  one  vulnerability  type  at  a  time. 


Vulnerability  type 


Any . 

ZJ 

mi 

input  validation  error 
(boundary  condition  error) 

(buffer  overflow) 
access  validation  error 
exceptional  condition  error 
environmental  error 
configuration  error 
race  condition 
design  error 
other  error 

Figure  B-12  —  Vulnerability  Type  Search  Filter 

(Operating  System)  OS  Type — This  filter  provides  the  ability  to  separate  the  results 
based  on  the  operating  system  effected.  Figure  B-13  shows  the  options  for  this 
filter  (the  Windows  NT  option  includes  Windows  2000  and  XP).  Note:  as  with  all 
drop  down  boxes  on  the  ICAT  search  page  the  user  may  select  only  one  OS  at  a 
time. 


OS  Type 


1  Any . 

. 3 

. I 

Unix 

Windows 

Windows  NT 

Apple 

Figure  B-13  —  Vulnerability  Type  Search  Filter 


Exposed  Component  Type — Provides  the  ability  to  filter  the  results  by  the  type  of 
component  effected  (e.g.,  user  application,  communications  protocol,  hardware, 
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etc.)  Figure  B-14  shows  the  options  for  this  filter.  Note:  as  with  all  drop  down 
boxes  on  the  ICAT  search  page  the  user  may  select  only  one  component  at  a  time. 


Exposed  component  type 


|Any . 

3 

operating  system 
network  protocol  stack 
user  application 
server  application 
hardware 

communication  protocol 
encryption  module 
other  type  of  component 

Figure  B-14  —  Exposed  Component  Type  Search  Filter 


Entry  Type — Provides  the  ability  to  filter  the  results  by  the  type  of  entry.  The  ICAT 
contains  two  type  of  entries  .  The  primary  entries  are  those  that  have  been  accept 
by  the  CVE  advisory  committee.  The  entries  start  with  the  prefix  “CVE.”  The  other 
types  of  entries  are  those  that  are  still  being  reviewed  by  the  CVE  committee  and 
begin  with  the  prefix  “CVN.”  Figure  B-1 5  shows  the  options  for  this  filter.  Note:  as 
with  all  drop  down  boxes  on  the  ICAT  search  page  the  user  may  select  only  one 
type  of  entry  at  a  time. 


Figure  B-1 5  —  Entry  Type  Search  Filter 

Entries  Since  the  Following  Date — Provides  the  ability  to  select  only 
vulnerabilities  published  after  particular  month  and  year  (back  to  January,  1 995)  as 
shown  in  Figure  B-1 6. 

Entries  since  the  following  |Any  MlJnth  J  ^  YeaI  J 


Figure  B-1 6  —  Entries  Since  the  Following  Date  Filter 

ICAT  Metabase  Search  Result 

Once  a  user  has  specified  a  search  parameter  and  clicked  on  the  appropriate 
search  button,  the  ICAT  will  provide  a  list  of  all  results  matching  his/her  search 
criteria  (see  Figure  B-1 7). 
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There  are  2916  matching  records  Displaying  matches  1  through  20 

Nexl  20  Matches 

J 

CAN  2001  06/0 

Summary: 

Buffet  overflow  in  6S0  line  pnnter  daemon  («i  Ipd  or  Ipd)  in  various 
BSD-based  operating  systems  shows  remote  attackers  to  execute 
arbitrary  code  wa  an  incomplete  pnnt  job  followed  by  a  request  to 
display  the  pnnter  queue 

Published  l More : 

10/3/2001 

Severity: 

High 

CAN .20010710 

Summary: 

NetBSD  1  5  and  earlier  and  FreeBSD  4  3  and  earher  allows  a  remote 
attacker  to  cause  a  denial  of  serwce  by  sending  a  large  number  of  IP 
fragemenls  to  the  machine,  exhausting  the  mbuf  pool 

Published  Before: 

9/20/2001 

Severity: 

Medium 

CAN -2001 0709 

Summary: 

Microsoft  IIS  4  0  and  before  wrren  installed  on  a  FAT  partition, 
allows  a  remote  attacker  to  obtain  source  code  of  ASP  IHes  via  a 

URL  encoded  with  Unicode 

Published  ftclore: 

9/20/2001 

Severity: 

High 

CAN  2001  0700 

Summary: 

Deniconrip  REXECD  1.05  and  earlier  allows  a  renvote  attacker  to 
cause  a  denial  of  service  (crash)  via  a  long  stnng 

Published  Before: 

9/20/2001 

Severity: 

Medium 

Figure  B-17  —  ICAT  Search  Results  List 

To  assist  the  user  in  identifying  the  search  results  that  are  applicable  to  their 
system(s),  the  ICAT  Metabase  provides  summary  information  on  each  result.  Click 
on  the  vulnerability  name,  which  is  the  number  in  blue,  will  provide  additional  details 
on  that  particular  vulnerability  or  exposure  (see  Figure  B-18). 
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Vulnerability  Name: 

This  r«f«r«nc*  is  to  j  norvNIST 

silt  ( 

CAN-2001 -0709 

Published  before: 

9/20/2001 

Summary: 

Microsoft  IIS  4  0  and  before,  when  installed  on  a  FAT  partition, 
allows  a  remote  attacker  to  obtain  source  code  of  ASP  files  via  a 
URL  encoded  with  Unicode 

Severity: 

High 

Vulnerability  type: 

Environmental  Error 

Exploitable  Range: 

Remote 

Loss  type: 

Confidentiality 

Reference  1: 

This  rat«r*nc«  is  to  j  norv  NIST 
3lt«  ( 

Source  Security  Focus 

Type:  General  and  Patch 

Name  VIGIIANTE-2001001 

http  //www  securityfocus  com/archive/1/192802 

Reference  2: 

This  refeienc*  is  to  M  noft-NIST 
««•  (  ) 

Source  Secunly  Focus 

Type  General  and  Patch 

Name  bid2909 

http  //www  securityfocus  com/bid/2909 

Reference  3: 

Thlt  rtttrenc*  is  to  i  non-NIST 
site  ( 

Source  ISS  X-Force 

Type:  General  and  Patch 

Name:  ns-umcode-asp-disclosure(|6742) 

http://xforce.iss  net/st atio6742.php 

Vulnerable  software 
and  versions: 

Microsoft,  IIS,  4.0,  and  previous 

Figure  B-18  —  Search  Result  Detail 

•  Vulnerability  Name — ICAT  uses  the  CVE  standard  vulnerability  naming 
scheme  to  name  each  vulnerability.  Vulnerabilities  will  be  named  either 
CVE-xxxx-yyyy  or  CAN-xxxx-yyyy.  The  CVE  prefix  is  attached  to 
vulnerabilities  that  have  been  reviewed  by  the  CVE  standard  advisory 
committee.  The  CAN  prefix  is  for  candidates  under  review  by  the  advisory 
committee.  The  candidates  have  been  filtered  by  MITRE  to  ensure  some 
degree  of  accuracy,  but  there  is  no  guarantee  that  a  CAN  entry  is  a  unique 
or  real  vulnerability.  The  xxxx  part  of  each  entry  represents  the  year  in 
which  the  vulnerability  entered  the  CVE  process.  The  yyyy  part  of  each 
entry  is  a  unique  number  assigned  to  entries  submitted  to  the  CVE 
committee  that  year.  When  a  CAN  entry  is  approved  by  the  CVE 
committee,  the  prefix  is  changed  from  CAN  to  CVE  while  leaving  the 
number  the  same. 

•  Published  Before — This  field  gives  an  indication  of  when  a  vulnerability 
was  discovered.  With  older  vulnerabilities,  the  date  used  was  the  earliest 
dating  from  among  publicly  available  sources.  For  vulnerabilities  released 
in  the  year  2001  and  beyond,  ICAT  uses  the  date  on  which  the 
vulnerability  was  added  to  ICAT. 

•  Summary — Provides  a  one-line  description  of  the  vulnerability.  This 
description  is  the  same  description  as  found  in  the  particular  vulnerability’s 
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standard  CVE  or  CAN  entry.  ICAT  provides  only  this  short  description  of 
the  vulnerability  because  the  purpose  of  ICAT  is  to  be  a  searchable  index 
of  vulnerabilities  instead  of  a  vulnerability  database.  The  purpose  of  this 
“summary”  and  the  other  vulnerability  attributes  is  to  quickly  allow  users  to 
determine  whether  or  not  a  particular  vulnerability  is  relevant.  Users  should 
use  the  references  found  in  each  ICAT  entry  to  obtain  complete 
descriptions  of  each  vulnerability  from  a  variety  of  outside  resources  (see 
next  section). 

•  Severity — ICAT  provides  a  severity  field  to  enable  one  to  quickly  judge 
the  impact  of  a  vulnerability.  Vulnerabilities  can  have  one  of  three  severity 
levels:  “High  severity”,  “Medium  severity”,  or  “Low  severity”.  It  is  difficult  to 
accurately  assign  such  ratings,  as  different  vulnerabilities  will  have  differing 
levels  of  impact  depending  upon  the  installed  software  base  of  an 
organization.  Despite  this  problem,  severity  labels  are  still  useful  indicators 
of  vulnerability  impact. 

o  A  vulnerability  is  “high  severity”  if: 

•  It  allows  a  remote  attacker  to  violate  the  security 
protection  of  a  system  (i.e.  gain  some  a  user  or  root 
account). 

•  It  allows  a  local  attack  that  gains  complete  control  of  a 
system. 

•  It  is  important  enough  to  have  an  associated  CERT/CC 
advisory. 

o  A  vulnerability  is  “medium  severity”  if: 

•  It  does  not  meet  the  definition  of  either  “high”  or  “low” 
severity. 

o  A  vulnerability  is  “low  severity”  if: 

•  The  vulnerability  does  not  typically  yield  valuable 
information  or  control  over  a  system  but  instead  gives  the 
attacker  knowledge  that  may  help  the  attacker  find  and 
exploit  other  vulnerabilities. 

•  The  vulnerability  is  inconsequential  for  most 

organizations. 

•  Exploitable  Range — A  vulnerability  can  enable  either  a  "local"  and/or 
"remote"  attack. 

o  Local — Attacks  that  utilize  the  vulnerability  can  be  launched 

directly  on  the  system  that  is  being  attacked.  The  attacker  must 
have  some  previous  access  to  the  system  in  order  to  launch  an 
attack  locally.  Note,  ICAT  still  defines  an  attack  as  local  if  an 
attacker  legally  Telnets  to  a  host  and  then  initiates  an  attack  on 
that  host.  The  attack  is  local  because  the  attacker  did  not  attack 
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the  telnet  server  itself  but  a  component  only  visible  to  logged  in 
users. 

o  Remote — Attacks  that  utilize  the  vulnerability  can  be  launched 

across  a  network  against  a  system  without  the  user  having 
previous  access  to  the  system. 

Loss  Type — Includes  the  traditional  three  types  ("availability", 
"confidentiality",  and  "integrity")  plus  an  additional  category  called  "security 
protection". 

o  Availability — A  vulnerability  is  given  the  “availability”  label  if  it 
enables  an  attack  that  directly  inhibits  a  user  (human  or  machine) 
from  accessing  a  particular  system  resource.  Denial  of  service 
attacks  are  availability  violations  by  ICAT's  definition. 

o  Confidentiality — A  vulnerability  is  given  the  “confidentiality”  label  if 
it  enables  an  attack  that  can  directly  steal  information  from  a 
system. 

o  Integrity — A  vulnerability  is  given  the  “integrity”  label  if  it  enables 

an  attack  that  can  directly  change  the  information  residing  on  or 
passing  through  a  system. 

o  Security  Protection — A  vulnerability  is  given  the  “security 
protection”  label  if  it  enables  an  attack  that  gives  the  attacker 
privileges  in  a  system  that  the  attacker  is  not  allowed  to  have  by 
the  access  control  policy  of  the  system.  The  "security  protection" 
label  may  appear  by  itself  or  in  three  other  variations:  “security 
protection  (gain  superuser  access)"  when  the  attack  allows  a 
hacker  complete  control  of  a  system,  "security  protection  (gain 
user  access)"  when  the  attack  allows  a  hacker  partial  control  over 
a  system,  “security  protection  (other)  when  the  attack  gi\es  the 
hacker  some  other  privilege  on  the  system. 

The  availability,  confidentiality,  and  integrity  attributes  are  included  in  a 
vulnerability  description  only  if  exercising  the  vulnerability  directly  violates 
one  of  these  properties.  If,  for  example,  a  vulnerability  can  give  an 
attacker  increased  privileges  thereby  allowing  the  attacker  to  violate 
availability,  only  the  security  protection  box  would  be  checked.  However,  if 
a  single  vulnerability  enables  two  different  attacks  (as  is  typical  with  buffer 
overflow  vulnerabilities),  one  of  which  violates  security  protection  and  the 
other  availability  directly,  then  both  corresponding  boxes  would  be 
checked. 

Vulnerability  Type — The  ICAT  Metabase  characterizes  each  vulnerability 
in  such  a  way  that  one  can  understand  the  type  of  software  problem  that 
produced  the  vulnerability.  Each  vulnerability  may  exhibit  one  or  more  of 
the  following  characteristics: 

o  Input  validation  error — A  vulnerability  is  characterized  as  an  “Input 
validation  error”  if  the  input  being  received  by  a  system  is  not 
properly  checked  such  that  a  vulnerability  is  present  that  can  be 


exploited  by  a  certain  input  sequence.  This  vulnerability  type  and 
its  subcategories  only  apply  to  input  that  is  malicious  or  otherwise 
malformed.  The  "Input  validation  error"  label  may  appear  by  itself 
or  in  two  other  variations:  “Input  validation  error  (Boundary 
overflow)”  and  “Input  validation  error  (Buffer  overflow)”.  These  two 
categories  are  discussed  below: 

■  Boundary  Overflow — A  vulnerability  is  characterized  as  a 
“Boundary  overflow”  when  the  input  being  received  by  a 
system,  be  it  human  or  machine  generated,  causes  the 
system  to  exceed  an  assumed  boundary  thereby  causing 
a  vulnerability.  For  example,  the  system  may  run  out  of 
memory,  disk  space,  or  network  bandwidth.  Another 
example  is  that  a  variable  might  reach  its  maximum  value 
and  roll  over  to  its  minimum  value.  Yet  another  example  is 
that  the  variables  in  an  equation  might  be  set  such  that  a 
division  by  zero  error  occurs.  Boundary  overflow  errors 
are  a  subset  of  the  class  of  input  validation  errors.  While  it 
could  be  argued  that  buffer  overflow  (discussed  next)  is  a 
type  of  boundary  overflow  error,  ICAT  puts  buffer 
overflows  in  a  distinct  category  given  their  importance. 

■  Buffer  Overflow — A  vulnerability  is  characterized  as  a 
“buffer  overflow”  if  the  vulnerability  is  caused  by  input 
being  received  by  a  system  that  is  longer  than  the 
expected  input  length.  If  the  system  does  not  check  for 
this  condition  then  the  input  buffer  fills  up  and  overflows 
the  memory  allocated  for  the  input.  By  cleverly 
constructing  this  extra  input,  an  attacker  can  cause  the 
system  to  crash  or  even  to  execute  instructions  on  behalf 
of  the  attacker. 

o  Access  Validation  Error — A  vulnerability  is  characterized  as  a 
“Access  validation  error”  if  a  system  is  vulnerable  because  the 
access  control  mechanism  is  faulty.  The  problem  lies  not  with  the 
user  controllable  configuration  of  the  access  control  mechanism 
but  with  the  mechanism  itself. 

o  Exceptional  Condition  Handling  Error — A  vulnerability  is 

characterized  as  an  “Exceptional  condition  handling  error”  if  a 
system  somehow  becomes  vulnerable  due  to  an  exceptional 
condition  that  has  arisen.  The  handling  (or  mishandling)  of  the 
exception  by  the  system  enables  a  vulnerability. 

o  Environmental  Error — A  vulnerability  is  characterized  as  an 

“Environmental  error”  if  the  environment  in  which  a  system  is 
installed  somehow  causes  the  system  to  be  vulnerable.  This  may 
be  due,  for  example,  to  an  unexpected  interaction  between  an 
application  and  the  operating  system  or  between  two  applications 
on  the  same  host.  Such  a  vulnerable  system  may  be  perfectly 
configured  and  provably  secure  in  the  developers  test 
environment,  but  the  installation  environment  somehow  violates 
the  developer's  security  assumptions. 
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o  Configuration  Error — A  vulnerability  is  characterized  as  a 
“Configuration  error”  if  user  controllable  settings  in  a  system  are 
set  such  that  the  system  is  vulnerable.  This  vulnerability  is  not  due 
to  how  the  system  was  designed  but  on  how  the  end  user 
configures  the  system.  ICAT  considers  it  a  configuration  error 
when  a  systems  ships  from  a  developer  with  a  weak  configuration. 

o  Race  Condition — A  vulnerability  is  characterized  as  a  “Race 
condition”  if  a  the  non-atomicity  of  a  security  check  causes  the 
existence  of  a  vulnerability.  For  example,  a  system  checks  to  see  if 
an  operation  is  allowed  by  the  security  model  and  then  performs 
the  operation.  However,  between  the  time  the  security  check  is 
performed  and  when  the  operation  is  performed,  the  environment 
changes  such  that  the  operation  is  no  longer  allowed  by  the 
security  model.  Attackers  can  take  advantage  of  this  small  window 
of  opportunity  and  convince  systems  to  perform  illegal  operations 
like  writing  to  the  password  file. 

o  Design  Error — A  vulnerability  is  characterized  as  a  “Design  error”  if 
there  exists  no  errors  in  the  implementation  or  configuration  of  a 
system,  but  the  initial  design  causes  a  vulnerability  to  exist. 

o  Other — Since  the  above  vulnerability  characteristics  are  not  a  true 
classification  scheme,  it  is  possible  that  a  vulnerability  will  not  fall  in 
any  of  them.  Any  such  vulnerability  is  characterized  as  vulnerability 
type  “Other.” 

•  Exposed  System  Component — The  exposed  system  component  field 
identifies  exactly  where  in  a  system  the  vulnerability  occurs.  The  possible 
types  are  "Operating  system",  "Protocol  stack",  "Server  application",  "Non¬ 
server  application",  "Hardware",  "Communication  protocol",  "Encryption 
module",  and  "Other  type  of  component".  A  vulnerability  may  in  some 
cases  be  assigned  multiple  types  in  this  field. 

•  Exposed  System  Type — The  exposed  system  type  field  identifies  in  what 
type  of  system  the  vulnerability  is  usually  present.  The  possible  types  are 
"Server",  "Workstation",  "Networking/Security  device",  and  "Other  device 
type". 

•  References— ICAT  provides  references  along  with  each  vulnerability  entry. 
These  references  link  an  ICAT  user  to  publicly  available  vulnerability 
database  and  patch  sites  that  contain  entries  about  the  particular 
vulnerability  being  viewed.  The  referenced  sites  have  no  affiliation  with 
ICAT  or  NIST  cannot  endorse,  verify,  or  guarantee  the  information  on 
those  sites.  For  each  reference,  ICAT  may  provide  the  following 
information: 

o  Source — The  source  is  the  name  of  the  vulnerability  database  or 
patch  site  on  which  the  vulnerability  is  described. 

o  Type — The  type  field  describes  what  kind  of  information  is  found  in 
this  source.  A  source  may  contain  general  information  on  the 
vulnerability,  a  patch,  or  a  combination  of  both.  The  exact  values 
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entered  into  this  field  are  of  the  following  set:  “General”,  “Patch”,  or 
“General  and  Patch”. 

o  Name — The  name  field  is  the  vulnerability  name  used  by  this 
particular  source  for  the  viewed  CVE  entry.  This  field  enables  one 
to  search  ICAT  using  non-standard  vulnerability  names  from  other 
vulnerability  databases. 

o  Link — The  link  field  contains  a  hyperlink  to  the  related  vulnerability 
entry  in  the  “Source”  field.  ICAT  links  users  directly  to  the  desired 
vulnerability  entries.  It  is  this  aspect  of  ICAT  that  makes  it  a  true 
“metabase”  of  information. 

•  Vulnerable  Software  and  Versions — ICAT  provides  a  list  of  vulnerable 
software  names  and  version  numbers  for  most  CVE  and  CAN  entries.  This 
list  is  provided  to  enable  users  to  search  for  vulnerabilities  associated  with 
their  software  versions.  If  software  is  listed  on  ICAT  entry,  the  related 
references  can  be  used  to  obtain  the  appropriate  patches  or  mitigations 
techniques.  ICAT  entries  typically  will  list  each  vulnerable  version  on  a 
separate  line.  Each  line  will  contain  a  vendor  name,  software  name,  and 
vulnerable  version  number.  This  information  is  obtained  from  various  public 
and  private  sources.  Much  of  this  information  is  obtained  (with  permission) 
from  CERT,  Security  Focus,  and  ISS  X-Force. 
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Appendix  C:  Vulnerability  Advisory  Resources 


Federal  Vulnerability  Advisory  Websites7 


Website 

URL 

Federal  Computer  Incident  Response  Center 
(FedCIRC) 

httD://www.fedcirc.aov/ 

DoD  Computer  Emergency  Response  Team 
(DoD-CERT) 

httD  ://afcert.  kel  1  v .  at .  m  i  1 

Navy  Computer  Incident  Response  Team 
(NAVCIRT) 

httD://infosec.sDawar.navv.mil 

Department  of  Energy's  Computer  Incident 
Advisory  Capability  (CIAC) 

httD://ciac.llnl.aov 

National  Infrastructure  Protection  Center 
(NIPC) 

httD://www.nioc.aov/ 

Private  Sector  Vulnerability  Advisory  Websites 


Website 

URL 

The  Software  Engineering  Institute's  CERT 
Coordination  Center  (CERT) 

htto://www.cert.ora/ 

Computer  Security  Incident  Response  Team  - 
World  Site  (CSIRT.WS) 

htto://www.csirt.ws/ 

Internet  Security  Systems  X-Force  (ISS  X- 
Force) 

htto  ://xforce.iss. net/ 

Security  Focus 

htto://www. securitvfocus.com/ 

CERIAS 

htto  ://www.cerias. ourdue.edu/ 

SANS  Institute 

htto://www.  sans,  ora 

SANS  lncidents.org 

httD://www.incidents.ora 

7  Please  note  several  of  these  sites  require  users  to  be  on  a  .gov  or  .mil  domain  in  order  to  access  some  or 
all  of  the  functionality  of  the  website. 
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Appendix  D:  Vulnerability  Scanners 


Vulnerability  Scanning  Tools? 


Tool 

Website 

Ope  rs 

Linux 

ites  on 

Win32 

CyberCop 

Scanner 

htto://www.  DaD.com/oroducts/ 

V 

y 

ISS 

Internet 

Scanner 

htto://www. iss.net/ 

y 

Nessus 

httD://www. nessus. ora/ 

V 

S  (client  only) 

SAINT 

httD://www.wwdsi.  com/saint/ 

v 

SARA 

httD://www-arc.com/sara/ 

V 

SATAN 

httD://www.fish.com/satan/ 

Using  Cybercop  Vulnerability  Scanner 

One  popular  vulnerability  scanner  is  CyberCop  Scanner  by  Network  Associates. 
This  commercial  vulnerability  scanner  like  most  commercial  and  freeware  scanners 
can  identify  a  numerous  common  vulnerabilities.  It  can  also  identify  a  limited 
number  of  esoteric  vulnerabilities.  However  it  does  provide  a  good  indication  of  the 
overall  security  stance  of  a  network.  Before  using  any  vulnerability  scanner,  it  is 
critical  to  get  the  latest  vulnerability  database  update.  All  scanners  rely  on  a 
database  of  known  weaknesses  and  if  this  is  not  the  latest  version,  the  scanner  will 
not  be  able  to  identify  the  latest  vulnerabilities.  To  update  CyberCop,  select 
“AutoUpdate”  see  Figure  D-1. 


1  CyberCop  Scanner  ► 

^  Active  Security  Configuration 

AutoUpdate 

^  CyberCop  Scanner 

CyberCop  Sentry 

NTCASL 
jjj]  Readme 

Figure  D-1  — CyberCop  AutoUpdate 


8  There  are  number  of  excellent  freeware  vulnerability  scanners  available  including  several  listed  in  this 
section .  However  great  care  should  be  used  in  selecting  freely  available  tools.  Generally, 
freeware/shareware  tools  should  not  be  used  unless  an  expert  has  reviewed  the  source  code  or  they  are 
widely  used  AND  are  downloaded  from  a  known  safe  repository.  There  are  many  cases  of  malicious  code 
being  hidden  in  freeware  tools.  Even  if  the  tool  appears  to  do  what  it  was  advertised  to  do  there  is  no 
guarantee  that  it  is  not  doing  something  else(such  as  sending  user  ids  and  passwords  to  a  malicious 
entity).  The  bottom  line  is  that  one  can  never  be  too  careful  when  using  freeware. 
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When  the  CyberCop  vulnerability  database  is  updated,  start  the  CyberCop  Scanner 
application  by  clicking  on  ‘CyberCop  Scanner”  in  the  Windows  Start  menu  (see  in 
Figure  D-1 1  just  below  AutoUpdate  feature).  This  will  open  the  CyberCop  Scanner 
application  (see  Figure  D-2) 


Figure  D-2  —  CyberCop  Scanner  Primary  Window 

Before  running  the  actual  scan  it  will  be  necessary  to  select  what  vulnerabilities  to 
test  for  and  what  hosts  or  subnets  to  scan.  To  configure  the  tests  to  run: 

1.  Click  on  Configure”  from  the  CyberCop  menu  bar. 

2.  Click  on  “Module  Settings.” 

This  will  open  the  “Module  Configuration  Dialog”  window  (see  Figure  D-3). 
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Figure  D-3  —  Module  Configuration  Dialog 

From  this  window,  a  user  can  select  the  tests  to  process.  This  window  has  three 
sub-windows.  In  the  upper  left  is  the  “Module  Groups”  sub-window  (CyberCop 
refers  to  each  test  as  a  “module”).  Similar  tests  are  sorted  in  module  groups  (e.g., 
FTP  tests,  Windows  tests,  etc.).  The  “Module  Groups”  window  allows  a  user  to 
select  and  deselect  entire  groups  of  tests  (modules).  The  “Module  Selection”  sub¬ 
window  (upper  right)  allows  the  user  to  select/deselect  specific  tests.  The  contents 
of  this  window  change  with  the  group  selected  in  the  “Module  Groups”  sub-window. 
The  “Module  Description”  sub-window  (lower  half)  provides  a  description  of  the 
selected  module  including  risk  level,  complexity,  popularity,  detailed  description  of 
vulnerability  and  sources  for  correction  (if  available).  Modules  with  a  ^  next  to 
them  are  “dangerous.”  That  is  they  can  have  a  negative  impact  on  the  host  being 
scanned  (e.g.,  crash  targeted  application,  denial  of  service,  freeze  TCP/IP  stack, 
etc.).  To  ensure  these  items  are  not  selected,  make  sure  to  click  on  the  “Unselect 
Dangerous”  button.  This  is  the  recommended  setting  except  for  experienced  users 
who  fully  understand  the  implications  of  selecting  these  tests. 

Next  it  will  be  necessary  to  configure  the  hosts  or  subnet  to  scan.  To  configure 
this: 

1.  Click  on  ‘Configure”  from  the  CyberCop  menu  bar. 

2.  Click  on  Scan  Settings.” 

This  will  open  the  “CyberCop  Scanner  Setup”  window  (see  Figure  D-4). 
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Figure  D-4  —  CyberCop  Scanner  Setup 

From  this  Window,  the  user  can  select  the  hosts  or  subnets  to  scan  and  where  to 
store  the  results.  Once  these  have  been  selected,  they  can  be  saved  to  a  template 
for  future  use,  if  required,  and  the  scan  can  be  started. 

The  time  a  scan  will  take  depends  on  the  number  and  type  of  tests  selected  and  the 
number  of  hosts  scanned.  It  can  vary  from  minutes  to  hours.  A  general  rule  of 
thumb  is  approximately  2-10  minutes  per  host  depending  on  the  number  of  tests 
(modules)  selected.  Once  the  scan  is  completed,  CyberCop  will  provide  a  detailed 
report  itemizing  the  vulnerabilities  discovered.  This  report  can  be  customized  to 
meet  the  needs  of  the  user.  A  partial  sample  of  a  Cyber  Cop  report  is  provided  in 
Figure  D-5. 
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Figure  D-5  —  CyberCop  Report  Partial  Sample 
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Appendix  E:  Using  Windows  Update 


Windows  Update  is  a  utility  provided  by  Microsoft  in  most  versions  of  Windows 
(including  some  versions  of  95  and  NT  and  all  versions  of  98,  ME,  2000  and  XP) 
that  allows  a  user  to  scan  their  computer  to  find  any  updates  that  are  available  at 
that  time  from  Microsoft  and  other  participating  vendors.  Figures  E-1  and  E-2 
demonstrate  the  two  different  methods  of  accessing  the  Windows  Update  utility.  It 
is  suggested  that  users  close  all  other  applications  before  initiating  the  Windows 
Update  feature. 


Figure  E-1  — Accessing  Windows  Update  Though  Internet  Explorer 

To  access  Windows  update  from  within  Internet  Explorer  browser,  click  on  Tools 
and  then  Windows  Update  in  the  pull-down  menu. 


Alternatively,  a  user  can  access  windows  update  from  the  Start  Menu  as 
demonstrated  in  Figure  E-2.  From  the  Windows  desktop,  click  on  the  Start  bar. 
From  the  menu,  click  on  the  Windows  Update  icon. 
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Figure  E-2  —  Accessing  Windows 
Update  Though  the  Start  Menu 


Either  of  these  options  will  launch  Microsoft  Internet  Explorer  (if  it  is  not  already 
active)  and  go  the  Microsoft  Windows  Update  website 
(htttp://windowsupdate. microsoft.com).  See  Figure  E-3  for  the  Windows  Update 
homepage. 


Figure  E-3  — Windows  Update  Homepage 


To  have  the  Windows  Update  scan  your  computer  for  updates,  click  on  the 
“PRODUCT  UPDATES"  link.  Note:  This  is  accomplished  without  sending  any 
information  to  Microsoft  or  transmitting  sensitive  information  on  your  host  over  the 
Internet.  The  Windows  Update  utility  will  commence  its  scan  of  the  user's  computer 
and  come  up  with  a  customized  product  update  catalog  specific  to  that  computer 
(see  Figure  E-4).  Having  Window  Update  automatically  check  your  system  has 
several  advantages.  This  check  assures  that  users  will  get  the  most  up-to-date  and 
accurate  versions  of  anything  they  choose  to  download  from  the  site.  Additionally, 
they  will  not  waste  time  downloading  components  that  are  already  installed. 
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3j  Checking  Available  Updates...  -  Microsoft  Internet  Explorer 


^jnjxj 


Please  Wait... 

Windows  Update  is  customizing  the  product  updates  catalog  for  your  computer. 
This  is  done  without  sending  any  information  to  Microsoft. 


Figure  E-4  — Windows  Update  Scan 


Once  Windows  Update  has  finished  scanning  the  users  machine,  it  will  generate  a 
list  of  recommended  updates  (see  Figure  E-5).  Users  can  browse  the  list,  decide 
which  components  they  want,  and  download  them  right  to  their  computer. 


Figure  E-5  —  Windows  Update  Recommend  Updates 

The  product  updates  are  broken  down  into  five  different  sections: 

•  Critical  Updates  and  Service  Packs— It  is  generally  suggested  that  users 
download  all  Critical  Update  Packages  as  these  fix  now  known  problems 
(often  security  issues)  with  their  specific  installation. 
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•  Picks  of  the  Month — These  are  new  releases  that  add  functionality  to 
Windows  but  are  not  required  to  fix  a  known  problem. 

•  Recommended  Updates— These  are  older  releases  that  add  functionality  to 
Windows  but  are  not  required  to  fix  a  known  problem. 

•  Additional  Windows  Features— These  are  updates  to  other  applications 
that  are  included  with  Windows  (e.g.,  Internet  Explorer,  Media  Player,  etc.). 

•  Device  Drivers — Listed  here  will  be  any  updated  device  drivers  for  you 
computer.  A  device  driver  is  a  program  that  controls  a  piece  of  hardware 
(such  as  a  printer,  monitor,  disk  drive,  or  video  card)  that  is  attached  to  your 
computer.  Note:  Third  parties  manufacture  most  hardware  and  device  drivers 
for  this  hardware  will  not  be  listed  here  unless  the  manufacturer  has  an 
agreement  with  Microsoft.  Generally  a  user  should  go  to  the  appropriate 
manufacturer’s  website  to  get  device  driver  updates. 

Certain  updates  can  only  be  downloaded  individually.  If  this  is  the  case,  Window 
Update  will  provide  notification  as  shown  in  Figure  E-6.  If  this  happens  the  user  will 
have  to  repeat  the  process  delineated  here. 


VBScript:  Windows  Update 


You  can  only  download  Internet  Explorer  5.5  Service  Pack  2  and  Internet  Tools  separately  from  other  components.  Click  OK  to 
return  to  the  Product  Updates  Catalog  and  download  Internet  Explorer  5.5  Service  Pack  2  and  Internet  Tools.  After 
installation,  you  can  return  to  Windows  Update  to  download  additional  components.  Click  Cancel  to  return  to  the  Product 
Updates  Catalog  without  downloading  Internet  Explorer  5.5  Service  Pack  2  and  Internet  Tools. 

OK  ~~|  Cancel 


Figure  E-6  — Windows  Update  Multiple  Downloads  not  Permitted  Warning 

After  selecting  the  patches  to  download,  the  Download  Checklist  page  loads  to 
confirm  the  selections  (see  Figure  E-7).  At  this  point  user  may  choose  to  view  the 
instructions,  start  the  download  and  install,  or  to  go  back  and  reselect  the  software. 
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Figure  E-7  — Windows  Update  Download  Checklist 

After  selecting  “Start  Download”  from  the  Download  Checklist  page,  an  additional 
screen  pops  up  to  confirm  your  selection  (see  Figure  E-8).  At  this  point  you  may 
choose  to  view  the  instructions,  license  agreement,  start  the  download  and  install 
(by  clicking  on  the  “Yes”  button),  or  to  go  back  and  reselect  the  software  that  you 
would  like  to  download  and  install  (by  clicking  on  the  “No”  button). 
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-|  Windows  Update  —  Web  Page  Dialog 


jUxJ 

Please  read  the  following  license  agreement.  Press  the  PAGE  DOWN  key 
to  see  the  rest  of  the  agreement. 


DAMAGES  REFERENCED  ABOVE  AND  ALL  DIRECT  OR  T| 

GENERAL  DAMAGES),  THE  ENTIRE  LIABILITY  OF  MICROSOFT 
AND  ANY  OF  ITS  SUPPLIERS  UNDER  ANY  PROVISION  OF  THIS 
SUPPLEMENTAL  EULA  AND  YOUR  EXCLUSIVE  REMEDY  FOR 
ALL  OF  THE  FOREGOING  SHALL  BE  LIMITED  TO  ACTUAL 
DAMAGES  INCURRED  BY  YOU  BASED  ON  REASONABLE 
RELIANCE  UP  TO  THE  GREATER  OF  THE  AMOUNT  ACTUALLY 
PAID  BY  YOU  FOR  THE  OS  COMPONENTS  OR  U.S.$5.00.  THE 
FOREGOING  LIMITATIONS,  EXCLUSIONS  AND  DISCLAIMERS 
SHALL  APPLY  TO  THE  MAXIMUM  EXTENT  PERMITTED  BY 
APPLICABLE  LAW,  EVEN  IF  ANY  REMEDY  FAILS  ITS  ESSENTIAL 
PURPOSE.  _ I 


Do  you  accept  all  the  terms  of  the  preceding  License  Agreement?  If  you 
choose  No,  Install  will  close.  To  install  you  must  accept  this  agreement. 


Security  Update,  May  30,  2001 

Security  Update,  May  1 0,  2001 

- 

Yes 

Security  Update,  February  1 2, 2001 

Security  Update,  February  5,  2001 

No 

Security  Update,  October  24, 2000 

zr 

l 

http :  //windowsupdate .  microso  *  Internet 


Figure  E-8  — Windows  Update  Confirmation  and  License  Agreement 


Upon  acceptance  of  the  license  agreement,  the  selected  patches  and  software  will 
be  downloaded  (see  Figure  E-9).  The  duration  of  the  download  will  depend  on 
several  factors  including  the  files  size  of  the  software  selected  and  connection 
speed. 


Figure  E-9  — Windows  Update  Download  Status  Window 


After  the  download  is  complete,  Microsoft  Windows  Update  will  start  the  install 
process  which  may  take  up  to  several  minutes  to  complete  (see  Figure  E-10). 
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Microsoft  Windows  Update 


.jnjxj 


Security  Update,  August  3,  2001 

Download  progress:  1 5389  KB/1 5389  KB 


Install  Progress: 

IT 

Cancel 


Figure  E-10  — Windows  Update  Install  Status  Window 


Once  the  install  is  successfully  completed  that  browser  Window  will  confirm  the 
success  (see  Figure  E-11). 


CJ  C 1  ***»  '?fv»rrqi  •■»■*>;  (Ktwhttp ,i>wh««9r<W-  nvosc^t  cr-jr  c**-6ic>  #  Ww»t 


Figure  E-11  — Windows  Update  Install  Success  Confirmation  Window. 

Often,  a  reboot  may  be  necessary  to  activate  the  updates  (see  Figure  E-12).  Click 
on  the  “Yes”  button  to  restart  the  computer.  Click  the  “No”  button  if  you  do  not  wish 
to  reboot  immediately  (changes  will  NOT  take  effect  until  a  the  computer  has 


69 


successful  rebooted).  If  Window  update  does  not  prompt  for  a  reboot,  then  the 
changes  to  not  require  it  and  are  effective  from  the  time  of  a  successful  install  (see 
Figure  E-1 1) 


Figure  E-12  — Windows  Update  Restart  Dialog  Box 

If  additional  patches  were  required  but  could  not  be  download  simultaneously, 
repeat  the  Microsoft  Windows  Update  process  as  required. 


70 


Appendix  F:  Using  Microsoft  Personal  Security  Advisor 


Microsoft  Personal  Security  Advisor  (MPSA)  is  a  site  provided  by  Microsoft  that 
allows  a  user  to  easily  check  the  security  and  patch  state  of  a  Windows  NT  4.0  or 
Windows  2000  computer  (http://www.microsoft.com/technet/mpsa/start.asp).  By 
using  this  website  and  associated  application,  a  user  can  scan  their  Windows 
NT/2000  computer  and  receive  a  detailed  customized  report  of  their  computer's 
security  settings  and  patch  level  along  with  recommendations  for  updates  and 
improvements. 

At  the  time  of  writing,  the  following  checks  are  included  in  MPSA.  Microsoft  will 
continue  to  update  this  service  as  additional  patches  are  releasee  or  when 
suggested  security  settings  change. 

•  Password  Strength  and  Length 

•  Services 

•  Macro  Virus  Protection 

•  Service  Packs 

•  Hotfixes 

•  RASMAN 

•  Auto  Login 

•  Auditing  Events 

•  Secured  File  System 

•  Restriction  of  Anonymous  Connections 

•  Shares 

•  Unusual  Administrators 

•  Security  Zones  for  Explorer  and  Outlook 


MPSA  does  have  some  limitations  that  users  should  consider  before  using: 

•  The  hotfix  checking  portion  of  this  tool  is  valid  for  English-language  systems 
only. 

•  Presently,  MPSA  is  intended  to  assess  only  Windows  NT  4.0  Workstation 
and  Windows  2000  Professional. 

•  MPSA  does  not  check  for  web  server  related  patches.  For  users  running 
Internet  Information  Server  (IIS)  or  Personal  Web  Services  (PWS)  on  their 
system,  its  is  recommended  that  they  use  the  HFNetChk  (see  Appendix  G) 
tool  to  check  for  appropriate  web  server  patches. 
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An  example  scan  using  MPSA  is  documented  in  the  following  example.  To  access 
the  MPSA  site  enter  its  URL  (see  above)  into  the  Address  Line  of  the  Internet 
Explorer  (note:  MPSA  requires  Internet  Explorer  5.0  or  later).  This  will  open  the 
MPSA  homepage  (see  Figure  F-1). 


Figure  F-1  —  MPSA  Homepage 

To  start  the  scan,  press  the  yellow  button  labeled  “Scan  Now”.  Note:  MPSA 
conducts  a  scan  without  sending  any  sensitive  information  to  Microsoft.  MPSA  is 
implemented  as  an  ActiveX  control  (application).  To  install  and  run,  you  must  click 
the  “Yes”  button  when  the  Security  Warning  window  pops  up  (see  Figure  F-2). 


Security  Warning 


Do  you  want  to  install  and  run  "MSSecure  XML  File" 
signed  on  1 0/2/2001  1 : 02  AM  and  distributed  by: 

Microsoft  Corporation 

Publisher  authenticity  verified  by  Microsoft  Code  Signing 
PCA 


Caution:  Microsoft  Corporation  asserts  that  this  content  is 
safe.  You  should  only  install/view  this  content  if  you  trust 
Microsoft  Corporation  to  make  that  assertion. 


r*  Always  trust  content  from  Microsoft  Corporation 


Yes  I  No  More  Info 

TT-1 .  -1- 
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Figure  F-2  —  MPSA  Active-X  Control  Security  Warning 
Once  a  user  selects  yes,  the  Active  X  control  is  downloaded  (should  take  less  than 
a  minute)  and  it  initiates  and  processes  its  scan  (see  Figures  F-3  and  F-4). 


Scanning... 


Processing  3  of  1 0  password  checks. 


Figure  F-3  —  MPSA  Active  Scanning 


Figure  F-4  —  MPSA  Scan  Processing 


Once  the  scan  is  completed  MPSA  will  generate  a  report  on  the  overall  security  and 
patch  level  of  the  scanned  computer.  Three  risk  levels  are  assigned  to  each  item 
as  shown  in  Figure  F-5. 


Legend 

Severe  Risk 

0 

Security  FYIs 

Potential  Risk 

A 

Unable  to  Scan 

A 

Strong  Security 

• 

Figure  F-5  —  MPSA  Report  Legend 

•  Severe  Risk — There  is  a  serious  vulnerability  in  the  system,  and  change  is 
recommended  immediately 

•  Potential  Risk — There  is  a  potential  vulnerability  in  the  system,  change  is 
highly  recommended. 

•  Strong  Security — No  vulnerability  is  detected  in  the  scanned  system. 

•  Security  FYls— An  issue  that  may  be  a  vulnerability  but  requires  further 
investigation. 

•  Unable  to  Scan — The  MPSA  was  unable  to  scan  for  this  item. 


The  final  report  provides  details  and  advice  on  each  of  the  tests  performed  (see 
Figure  F-6). 
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Figure  F-6  —  Final  Report 

Clicking  on  the  hyperlinks  will  provide  additional  details  as  shown  Figure  F-7. 


Figure  F-7  —  Final  Report  Details 
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An  important  point  to  note  when  using  the  MPSA  scanner  is  that  it  must  be  run 
again  after  any  vulnerability  is  patched.  While  all  steps  may  be  correctly 
implemented  to  patch  a  system,  there  still  exists  the  possibility  that  one  patch  may 
“unfix”  another.  For  this  reason  it  is  important  to  always  scan  again  to  double  check 
for  correct  operation. 


75 


Appendix  G:  Using  Microsoft  Network  Security  Hotfix  Checker 


Microsoft  Network  Security  Hotfix  Checker  (HfNetChk)  is  acommand  line  tool 
written  by  Microsoft  to  access  the  patch  status  for  Windows  NT  4.0  and  Windows 
2000  operating  systems  as  well  as  hotfixes  for  Internet  Information  Services  (IIS) 

4.0  and  5.0,  SQL  Server  7.0  and  2000,  and  Internet  Explorer  5.01  and  later.  While 
less  easy  to  use,  it  supports  more  Microsoft  Products  than  either  Microsoft  Windows 
Update  or  MPSA. 

After  downloading  and  installing  HfNetChk,  run  hfnetchk.exe  from  the  command 
line.  The  program  will  then  attempt  to  download  an  Extend  Markup  Language 
(XML)  file  from  Microsoft.  This  XML  file  contains  the  information  on  the  current 
patch  and  update  status  of  the  programs  and  operating  systems  being  checked. 


Figure  G-1  —  Running  Hfnetchk 


Before  continuing  with  the  actual  scan,  you  must  agree  to  the  installation  and 
running  of  the  downloaded  XML  file  (see  Figure  G-2). 
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Figure  G-2  —  Installing  XML  File 

After  clicking  on  “Yes”  button,  the  program  will  then  load  the  XML  files  and  scan  the 
computer.  The  results  listed  on  the  command  line  screen  will  show  only  limited 
information  (see  Figure  G-3) 
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Figure  G-3  —  Hfnetchk  Output 

Although  the  listed  information  can  be  useful,  the  format  and  lack  of  additional 
information  can  leave  the  user  desiring  more.  To  correct  this  deficiency  there  is  a 
freeware  tool  Maximized  Software  Hotfix  Reporter  comes  in  to  play.  This  utility 
works  in  conjunction  with  hfnetchk  to  display  the  results  in  an  easy  to  read  HTML 
format  with  hyperlinks  making  it  easy  to  download  the  associated  patches  and 
hotfixes.  This  utility  can  be  found  at 

http://www.maximized.com/freeware/hotfixreporter/  (see  Figure  G-4). 
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Figure  G-4  —  Maximized  Software  Website 

Download  by  clicking  on  the  hyperlink  Download  Hotfix  Reporter 

Run  the  setup  program  to  install  Hotfix  Reporter.  The  Hotfix  Reporter  must  be 
installed  in  the  same  directory  as  HfNetChk  (see  Figure  G-5). 


yH  Maximized  Software  Hotfix  Reporter  3.2  Setup 


xj 


Select  Destination  Directory 


Hotfix  Reporter  must  be  installed  into  the  same  directory  as  the  HfNetChk  tool 
from  Microsoft.  If  you  have  not  yet  installed  this  tool,  then  please  exit  setup  and 
download  HfNetChk  from  httpV/www. microsoft.com/security/ 


Please  select  the  directory  containing  HfNetChk.EXE. 


C:\Program  FileskH  f  N  etChk 

Browse... 

Current  Free  Disk  Space: 

Free  Disk  Space  After  Install: 

80352  k 
80274  k 

<  Back 

Next  > 

Cancel 


Figure  G-5  —  Installing  Hotfix  Reporter 
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After  installation,  launch  the  Hotfix  Reporter  from  the  Windows  Start  menu.  The 
execution  of  the  Hotfix  reporter  will  very  similar  to  that  of  HfNetChk  since  they  work 
together  (See  Figure  G-6). 


Figure  G-6  —  Running  HfNetChk  with  Hotfix  Reporter 


When  HfNetChk  attempts  to  install  and  run  the  latest  XML  file  from  Microsoft,  the 
user  will  need  to  click  “Yes”  to  continue  the  operation  (See  Figure  G-7). 


Do  you  want  to  install  and  run  "MSSecure  XML  File" 
signed  on  10/2/2001  1:02  AM  and  distributed  by: 

Microsoft  Corporation 


Publisher  authenticity  verified  by  Microsoft  Code  Signing 
PCA 


Caution:  Microsoft  Corporation  asserts  that  this  content  is 
safe.  You  should  only  install/view  this  content  if  you  trust 
Microsoft  Corporation  to  make  that  assertion. 


r  Always  trust  content  from  Microsoft  Corporation 


No  More  Info 


Figure  G-6  —  Installing  Microsoft  XML  Data  File 

Once  HfNetChk  has  completed  it  scan,  the  Hotfix  Reporter  will  then  open  a 
Hypertext  Markup  Language  (HTML)  file  in  the  default  web  browser.  This  provides 
results  in  a  more  readable  and  usable  format  than  that  of  HfNetChk  alone.  These 
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results  are  also  stored  locally  and  can  be  reviewed  at  a  later  date.  As  with  the 
MPSA,  it  is  important  to  run  the  Hotfix  Reporter  again  after  any  and  all  updates  are 
run  to  ensure  that  nothing  has  been  undone. 
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